IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Inspired by: https://github.com/systemd/systemd/pull/24141
Calling fd_is_mountpoint() with AT_EMPTYPATH and an empty filename can
only work if we have new statx() available. If we do not, we can still
make things work for directories, but not for other inodes (since there
we cannot query information about the parent inode to compare things.)
Hence, let's handle and test this explicitly, to support this to the
level this is possible.
With this update, Arch Linux keyring updates will be automatically
pulled in instead of having to update to a new mkosi commit every
time the keyring gets outdated.
For now, this simply outputs the PCR hash values expected for a kernel
image, if it's measured like sd-stub would do it.
(Later on, we can extend the tool, to optionally sign these
pre-calculated measurements, in order to implement signed PCR policies
for disk encryption.)
Previously, the tree output of discovered boot laoders in the ESP would
look like this:
Available Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/0c6f41ed-2573-4723-8c84-23681f9d1c28)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot v250.7-1.fc36)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot v250.7-1.fc36)
With this change the tree branches are corrected to look like this:
Available Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/0c6f41ed-2573-4723-8c84-23681f9d1c28)
File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot v250.7-1.fc36)
└─/EFI/BOOT/BOOTX64.EFI (systemd-boot v250.7-1.fc36)
Ahhh! So much nicer. This incorrect tree drawing has been bugging me for
so long. Finally I can sleep at night again!
This is not actually used (or even supposed to be used) in clean
codepaths, but is tremendously useful when verifying things work
correctly, as a debugging tool.
Report whether the devicetree + sort-key boot loader spec type #1
fields are supported, and whether the "@saved" pseudo-entry is
supported.
Strictly speaking, thes features have been added in versions that are
already released (250+), so by adding this those version even though
they support the features will be considered not supporting them, but
that should be OK (the opposite would be a problem though, i.e. if we'd
assume a boot loader had a feature it actually does not).
These three features are features relevant to userspace, as it allows
userspace to tweak/genereate BLS entries or set EFI vars correctly.
Other features (i.e. that have no impliciations to userspace) are not
reported.
Let's be a bit more careful when converting the UTF-16 cmdline to ASCII.
Let's convert all characters out of the printable ASCII range to spaces,
instead of blindly relying on C's downcasting behaviour.
systemd-boot reports its features via the LoaderFeatures EFI variable.
Let's add something similar for stub features, given they have been
growing.
For starters only define four feature flags. One is a baseline feature
we pretty much always supported (see comment in code), two are features
added in one of the most recently released systemd version, and the
final one, is a feature we added a few commits ago.
This is useful for userspace to figure out what is supported and what
not.
Let's grab another so far unused PCR, and measure all sysext images into
it that we load from the ESP. Note that this is possibly partly redundant,
since sysext images should have dm-verity enabled, and that is hooked up
to IMA. However, measuring this explicitly has the benefit that we can
measure filenames too, easily, and that all without need for IMA or
anything like that.
This means: when booting a unified sd-stub kernel through sd-boot we'll
now have:
1. PCR 11: unified kernel image payload (i.e. kernel, initrd, boot
splash, dtb, osrelease)
2. PCR 12: kernel command line (i.e. the one embedded in the image, plus
optionally an overriden one) + any credential files picked up by
sd-stub
3. PCR 13: sysext images picked up by sd-stub
And each of these three PCRs should carry just the above, and start from
zero, thus be pre-calculatable.
Thus, all components and parameters of the OS boot process (i.e.
everything after the boot loader) is now nicely pre-calculable.
NOTE: this actually replaces previous measuring of the syext images into
PCR 4. I added this back in 845707aae2,
following the train of thought, that sysext images for the initrd should
be measured like the initrd itself they are for, and according to my
thinking that would be a unified kernel which is measured by firmware
into PCR 4 like any other UEFI executables.
However, I think we should depart from that idea. First and foremost
that makes it harder to pre-calculate PCR 4 (since we actually measured
quite incompatible records to the TPM event log), but also I think
there's great value in being able to write policies that bind to the
used sysexts independently of the earlier boot chain (i.e. shim, boot
loader, unified kernel), hence a separate PCR makes more sense.
Strictly speaking, this is a compatibility break, but I think one we can
get away with, simply because the initrd sysext images are currently not
picked up by systemd-sysext yet in the initrd, and because of that we
can be reasonably sure noone uses this yet, and hence relies on the PCR
register used. Hence, let's clean this up before people actually do
start relying on this.
Here we grab a new – on Linux so far unused (by my Googling skills, that
is) – and measure all static components of the PE kernel image into.
This is useful since for the first time we'll have a PCR that contains
only a PCR of the booted kernel, nothing else. That allows putting
together TPM policies that bind to a specific kernel (+ builtin initrd),
without having to have booted that kernel first. PCRs can be
pre-calculated. Yay!
You might wonder, why we measure just the discovered PE sections we are
about to use, instead of the whole PE image. That's because of the next
step I have in mind: PE images should also be able to carry an
additional section that contains a signature for its own expected,
pre-calculated PCR values. This signature data should then be passed
into the booted kernel and can be used there in TPM policies. Benefit:
TPM policies can now be bound to *signatures* of PCRs, instead of the
raw hash values themselves. This makes update management a *lot* easier,
as policies don't need to be updated whenever a kernel is updated, as
long as the signature is available. Now, if the PCR signature is
embedded in the kernel PE image it cannot be of a PCR hash of the kernel
PE image itself, because that would be a chicken-and-egg problem. Hence,
by only measuring the relavent payload sections (and that means
excluding the future section that will contain the PCR hash signature)
we avoid this problem, naturally.
the measurement calls can succeed either when they actually measured
something, or when they skipped measurement because the local system
didn't support TPMs.
Let's optionally return a boolean saying which case it is. This is later
useful to tell userspace how and if we measured something.
Everywhere else that `conf.get('ENABLE_*')` is used as a boolean key for
something (for example in if statements) it always checks if == 1, but
in this one case it neglects to do so. This is important because
conf.get yields the same int that was stored, but if statements require
booleans.
So does executable's "install" kwarg, at least according to the
documentation. In actuality, it accepts all types without sanity
checking, then uses python "if bool(var)", so you can actually do
`install: 'do not'` and that's treated identical to `true`. This is a
type-checking bug which Meson will eventually fix.
muon fails on the same code, today.
Passing a file as a command argument in string form assumes that
run_command has the current subdir as its cwd, but Meson's documentation
*explicitly* calls this out as undefined and wrong to use.
Indeed, muon has a different implementation that uses a different cwd,
and this argument cannot be found. Instead, passing a files() object
means that it's the job of meson itself to verify the file exists, then
pass it to the run_command in some format that guarantees it is a valid
path reference.
When translations are disabled, it's not necessary to `import('i18n')`
and do nothing with it. Also, importing it is (slightly) slow as Meson
needs to load another implementation file from disk, so why bother with
that work?
More particularly, muon does not yet implement this module and fails to
setup. Since there's already an option to disable using it, it makes
sense to let that option completely skip the not-implemented
functionality and actually succeed.
