diff options
| author | Lennart Poettering <lennart@poettering.net> | 2022-07-13 18:26:44 +0200 |
|---|---|---|
| committer | Yu Watanabe <watanabe.yu+github@gmail.com> | 2022-07-15 08:31:34 +0900 |
| commit | 8de7de462b73959d34cb50c059f5e806227c99b7 (patch) | |
| tree | d57cafdf6e5cc88955722251eb9cd08924e26468 /man/systemd.exec.xml | |
| parent | 08894b568f03fc06bb961c6c731be0c877ff7786 (diff) | |
| download | systemd-8de7de462b73959d34cb50c059f5e806227c99b7.tar.gz | |
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
Diffstat (limited to 'man/systemd.exec.xml')
| -rw-r--r-- | man/systemd.exec.xml | 14 |
1 files changed, 11 insertions, 3 deletions
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 |