objcopy seems to expect that the offset passed to --change-section-vma
is absolute instead of relative to ImageBase. If this is not accounted
for an invalid image is created that cannot be loaded:
0 .osrel 0000016b 0000000200016000 0000000200016000 00000400 2**2
…
6 .text 0000d242 0000000140001000 0000000140001000 00c6e800 2**4
This isn't an issue with gnu-efi based PE images, but natively created
ones will have a non-zero ImageBase.
Pass the joined arguments to polkit as command_line property like
pkexec does. Obviously not exactly perfect as it lacks quoting. Good
enough for polkit rules to check whether a program was called with
or without arguments though.
It is pretty convenient to add .cmdline using /proc/cmdline like
this:
--add-section .cmdline=/proc/cmdline --change-section-vma .cmdline=0x25000
However, it always returns a trailing newline, and stub will
convert it to a whitespace by mangle_stub_cmdline() in next boot.
Thus the resulting /proc/cmdline would contain a trailing
whitespace. When /proc/cmdline is used to generate .cmdline again,
the resulting UKI is mangled.
To address this kind of inconvenience, mangle_stub_cmdline() should
skip converting the trailing newline, and try to chomp all the
trailing whitespaces.
Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
We never use the return value, and it's confusing and kinda pointless
what we return there.
Hence drop it.
Originally noticed by: tristone13th <tristone13th@outlook.com>
Alternative to: #25810
The text said /dev/tty* as a whole was the VT subsystem and that VT is
not supported in containers.
But that's not accurate as /dev/tty* will match /dev/tty too and that
one device node is special and is not related to VT: it always points to
the current process own controlling tty, regardless what that is.
hence, rewrite /dev/tty* as /dev/tty[0-9]*.
We want to make use of that when formatting file systems, hence let's
pull in these modules explicitly.
(This is necessary because we are an early boot service that might run
before systemd-tmpfiles-dev.service, which creates /dev/loop-control and
/dev/mapper/control.)
Alternatively we could just order ourselves after
systemd-tmpfiles-dev.service, but I think there's value in adding an
explicit minimal ordering here, since we know what we'll need.
Fixes: #25775
EFI_LOADER_VARIABLE() already applies to the stringify to construct the
path of EFI variable in efivars, so it is wrong to enclose the name of
EFI variable with the quotes. Otherwise, the following errors are
reported.
Reading EFI variable /sys/firmware/efi/efivars/StubFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrKernelImage"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrKernelImage"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrKernelParameters"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrKernelParameters"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrInitRDSysExts"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrInitRDSysExts"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
This is useful to make the dissection logic at boot a bit safer, as we
can reference device nodes by diskseq.
This locks down dissection a bit, since it makes it harder to swap out
the backing device between the time we dissected and validated it, until
we actually mounted it.
This is not complete though, as /bin/mount would have to verify the
diskseq after opening the diskseq symlink again.
See: https://github.com/util-linux/util-linux/issues/1786
This allows FIDO2 users to wipe out password slots and still be able to
enroll new key slots via systemd-cryptenroll. Note that when the user
wants to both unlock with a FIDO2 token and enroll a new FIDO2 token,
they cannot be set to automatic discovery. This is to safeguard against
confusion, because there will be multiple tokens connected to the system
when doing so -- and we require users to explicitly confirm which one to
use for unlocking and which one to use for enrollment.
Addresses #20230 for the FIDO2 case.
`acquire_fido2_key_auto()` will not be used in PLAIN mode, and
parameters such as the salt will be acquired from the LUKS header.
Parameters intended for PLAIN mode are useless in
`acquire_fido2_key_auto()`.