As in the previous commit, also enable the measurement logic when
activating Verity via veritsetup rather than the dissection logic.
The logic stays close to the interface of cryptsetup for measuring the
volume key.
Let's hook up the dissection logic with the new measurement infra, and
issue the measurement after successfully unlock an image, but before
returning to the caller.
Note that ideally we'd do this measurement in the kernel, so that we can
place it after authenticating the root hash, but before activating the
medium. One day we should be able to do that via eBPF based on userspace
policies, but for now, this would require too much kernel rework.
Let's however make sure our measurements only contain data that the
kernel could know too, so that we hopefully can move these measurements
to the kernel without changing their formatting.
This adds infrastructure for measuring Verity root hashes from
userspace, along with he issuer/serial of the signatures used to unlock
them.
We measure the triplet of volume name, root hash and issuer/serial. if
confext/sysext use different signing keys then this ensures the event
log carry information about the type of image measures.
Once we start measuring Verity volumes as we activate them we want to
include information about the signature keys used, so that we can have
distinct ones for confext and for sysext and ther purposes and thus have
a cryptograpically protected hint about the kind of image we have
activated in the event log.
Ideally we'd measure a fingerprint of the signing certificate here, but
we don't have that here typically (as PKCS7 signatures used here
typically do not embed that), hence use the next best thing: the issuer
name and the serial number.
I thnk it's crucial we start to measure Verity images as we activate
them, so that the event log has a full trace of the compisition of the
system. hence let's introduce a new NvPCR for this purpse, under the
name "verity".
It think we should move most measurements out of the individual tools
requesting them and into the pcrextend service via Varlink, so that
fewer components require access to the TPM.
This only works however, if we can actually write full-blown event log
records via this mechanism, and for that we still were missing access to
the userspace event type we insert into the event log. Add that.
Let's pick the default NvPCR name to use inside of cryptsetup itself, instead
of in the generator. I think this is the better choice, since it means
the default can also be used if the regular verittab generator is used
instead of the gpt-auto generator.
Motivation:
Currently, when setting the default boot pattern, boot assessment status
is not taken into account. This means that with boot assessment enabled,
when an explicit boot entry is configured as the default entry using an
EFI var, as is common for instance in A/B boot schemes, the configured
entry will be booted indefinitly, regardless of the entry's boot
assessment status.
In order to allow for this use case in combination with boot assessment,
we introduce a new `preferred` keyword, both in the config file and in the
bootctl CLI, that acts very similar to the existing `default` keyword but
takes boot assessment into account and never selects any entries that
have been marked as bad.
If the preferred pattern does not resolve to any bootable entry, and a
default pattern is also specified, then the default pattern will be
considered next, and we may then still select a known-bad entry to be
booted.
Fixes: https://github.com/systemd/systemd/issues/31215
Fixes: https://github.com/systemd/systemd/issues/40192
The current code incorrectly subtracts ImageBase from section
VirtualAddress values when loading sections into memory. This is based
on a misunderstanding of the PE specification.
VirtualAddress in section headers is the address of the first byte of
the section relative to the image base when the section is loaded into
memory. In other words, VirtualAddress is already an RVA measured from
the image base, it is definitely NOT an absolute address that needs to
be adjusted.
So when loading a PE image into a newly allocated buffer, sections
should be copied to buffer + VirtualAddress, regardless of what
ImageBase says. The ImageBase field merely indicates the *preferred*
load address, it does not affect how section RVAs are interpreted.
This happens to not cause issues when ImageBase was 0 (since
VirtualAddress - 0 = VirtualAddress), which is why this bug went
undetected on modern kernels. However, it fails with kernels that have
non-zero ImageBase values.
So let's remove the nonsensical VirtualAddress < ImageBase check, and
remove the ImageBase subtractions from section loading offsets. This
lets all kernel UKIs work properly again.
Fixes: #40342
There's not going to be any query if polkit support is
disabled at build time, so always check the peer's privileges
in that case
Follow-up for f5a12ceaed
Let's check if we're already in the right namespaces and call connect()
directly if that's the case. This can easily happen when the machine is
specified as .host or so.
These checks may rely on /proc on older kernels which we could lose access
to by joining namespaces so let's do all the checks first and then join
namespaces.
In 5c05a339c6 I retroactively changed the NEWS
entry for v259. But this is very confusing, because it looks like the original
change never happened and it's not clear what is being reverted.
Let's restore the original text, and just add a short note, but then move
the new text to the section for v260.
XDG_SESSION_EXTRA_DEVICE_ACCESS will now take a colon-separated list of
identifiers. For every identifier $ID, the session is granted access to all
devices tagged as "xaccess-$ID" in udev.
Fixes: #40634
Mostly consists of fixes to
- use the same sector_size as the fdisk context we are using, when
converting between sectors returned by libfdisk to bytes. Fixes#30394 ,
Fixes#30393
- Use the explicit sector size if specified in the home record when are
probing the image file using libblkid. Fixes#30393
Also contains some other improvements with using physical block devices.
- Automatically probe sector size of physical block device, if user does
not pass luks-sector-size explicitly.
- Assign partitions to 1 MiB boundaries, as it is the standard practice
followed by all tools, fdisk, gptfdisk, gnu parted etc.
- Avoid stacking of loop device on top of physical block device in
home_create_luks as it leads to degradation of discard operations, and
mkfs getting stuck.
This is a general cleanup of the sensors hwdb file divides into several
commits per brand.
I have merged the devices that use the same matrices, clean up a little
some clear dmi matches, and apply a inline comment with the device where
is certainly very clear way to display.
My idea is to do more cleanup steps but actually will require more
effort to achieve complete dmis, I can do it with little time, and some
consensus for comment styling.
About the comment styling actually I thing we could follow two rules at
the same time: inline comment when the dmi match is short and there is
no additional many information than just the model, and the other one
comment above the dmi match when is too long or there are need to add
more info.
Fix for specific case #30393 where 4k sector luks container is created
on a 512b device. In this case the partition table needs to be 512b,
else the kernel will not be able to find the partition, and we will
have to create a loop device to translate the partition table to 4k.
Ensure we don't create a loop device on top of a physical block device.
This leads to huge performance degradation of discard operations if the
physical device does not support discard_on_zeroes.
- loop device historical semantics dictates that when the device is
discarded, it needs to return zero data on read. This can be
implemented easily on a filesystem. since fallocate zero-range
would return immediately & the holes are handled at the filesystem
level to return zero data on read.
- For a raw block device, the feature (discard_zeroes_data) depends on
the capabilities of the physical device that is exposed to the
block layer by the driver. This means that to guarantee that the loop
device stacked on a block device returns zero on discarded data,
it needs to convert discarded range into write_zero op on the block device.
https://github.com/torvalds/linux/blob/63676eefb7a026d04b51dcb7aaf54f358517a2ec/drivers/block/loop.c#L773
For example on one of my local nvme I can see the following:
cat /sys/class/block/nvme1n1/queue/write_zeroes_max_bytes
131072
cat /sys/class/block/nvme0n1/queue/discard_max_hw_bytes
2199023255040
This means maximum size of a write_zero operation can be 128KiB &
maximum size of discard operation can be 2TiB on the block device.
So discarding for example 1TB of data, which would be a single block
device operation, gets split into 8.3 million block device operations
when issued on top of stacked loop device.
If there is an explicit sector size specified in the user record,
use the same when probing the file using libblkid. The default
is 512 bytes, which will not be able to find the signatures, if the
partition table on regular file was created assuming 4k sectors
Lennart Poettering
r-vdp
Yu Watanabe
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Mike Yuan
Jörg Behrmann
Alessandro Astone
AsciiWolf
scarlet-storm
David Santamaría Rogado