From 8de7de462b73959d34cb50c059f5e806227c99b7 Mon Sep 17 00:00:00 2001
From: Lennart Poettering <lennart@poettering.net>
Date: Wed, 13 Jul 2022 18:26:44 +0200
Subject: pid1: import creds from SMBIOS too, not just qemu's fw_cfg

This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.

Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.

Pros and cons of each:

SMBIOS OEM vendor strings:
   - pro: fast, because memory mapped
   - pro: somewhat VMM independent, at least in theory
   - pro: qemu upstream sees this as the future
   - pro: no additional kernel module needed
   - con: strings only, thus binary data is base64 encoded

fw_cfg:
   - pro: has been supported for longer in qemu
   - pro: supports binary data
   - con: slow, because IO port based
   - con: only qemu
   - con: requires qemu_fw_cfg.ko kernel module
   - con: qemu upstream sees this as legacy
---
 man/systemd.exec.xml | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

(limited to 'man/systemd.exec.xml')

diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 3d7ec1e202..055858ef04 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -3125,12 +3125,20 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
         <para>The service manager itself may receive system credentials that can be propagated to services
         from a hosting container manager or VM hypervisor. See the <ulink
         url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> documentation for details
-        about the former. For the latter, use the <command>qemu</command> <literal>fw_cfg</literal> node
+        about the former. For the latter, pass <ulink
+        url="https://www.dmtf.org/standards/smbios">DMI/SMBIOS</ulink> OEM string table entries (field type
+        11) with a prefix of <literal>io.systemd.credential:</literal> or
+        <literal>io.systemd.credential.binary:</literal>. In both cases a key/value pair separated by
+        <literal>=</literal> is expected, in the latter case the right-hand side is Base64 decoded when
+        parsed (thus permitting binary data to be passed in). Example qemu switch: <literal>-smbios
+        type=11,value=io.systemd.credential:xx=yy</literal>, or <literal>-smbios
+        type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=</literal>. Alternatively,
+        use the <command>qemu</command> <literal>fw_cfg</literal> node
         <literal>opt/io.systemd.credentials/</literal>. Example qemu switch: <literal>-fw_cfg
         name=opt/io.systemd.credentials/mycred,string=supersecret</literal>. They may also be specified on
         the kernel command line using the <literal>systemd.set_credential=</literal> switch (see
-        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
-        and from the UEFI firmware environment via
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) and from
+        the UEFI firmware environment via
         <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 
         <para>If referencing an <constant>AF_UNIX</constant> stream socket to connect to, the connection will
-- 
cgit v1.2.1