systemd
systemd copied to clipboard
systemd
Measure drivers loaded by systemd-boot
Component
systemd-boot
Is your feature request related to a problem? Please describe
All components of the chain should be measured and systemd-boot can load drivers for extra FS support and such, but as far as I know, those arent measured which means there is a security hole in which a bad actor would be able to inject a driver or change it and the measurements would be the same
Describe the solution you'd like
Drivers to be measured as all other parts of the boot chain
Describe alternatives you've considered
No response
The systemd version you checked that didn't have the feature you are asking for
No response
firmware measures all executed code anyway, including drivers. are you seeing things differently in the tpm event log after boot?
firmware measures all executed code anyway, including drivers. are you seeing things differently in the tpm event log after boot?
Not really, its just that the drivers are not mentioned anywhere in the docs about TPM measurements (https://github.com/uapi-group/specifications/blob/main/specs/linux_tpm_pcr_registry.md) so I was not certain if it was being measured or not and assumed they aren't, as they are not mentioned.
Are they really? Maybe we should update the docs to reflect that :D
firmware measures all executed code anyway, including drivers.
Can you expand that bit please?
To my understanding systemd-boot can use external drivers - but that means that also external drivers should be included during calculation of the expected measurements.
Otherwise it just looks like that systemd-boot can load external software without being noticed by any measurement (as we don't have to measure the external driver) which seems to suggest that the external software isn't measured at all and systemd-boot can load arbitrary software.
For example - systemd-boot can use external drivers, for instance https://github.com/pbatard/efifs to support booting EFI files from ext partitions - but if that is not included in the measurement it looks like it can be used to bypass measurements.
we use the uefi driver load apis, and afaik they measure what they load, implicitly. It's a firmware feature, and we don't have to do anything special for that at all.
we use the uefi driver load apis, and afaik they measure what they load, implicitly. It's a firmware feature, and we don't have to do anything special for that at all.
Firmware specifications can vary much - especially in term of UEFI as it is quite open to vendors to implement it correctly - besides, I cannot find any information around UEFI drivers being measured by firmware, at least in the specs.
Is this something systemd-boot is interested in at some point? While I understand the expectation is the firmware to do measurements, the reality is that it really depends on vendor implementations. It's hard to build immutable systems that are built outside the target system programmatically as we cannot bind to lower PCRs and pre-calculate measurement outside of that specific device.
I really think that this could undermine the security aspects of Trusted Boot to some extents. Just for a little bit of context, for the Kairos project (https://github.com/kairos-io) we are trying to build against the Trusted Boot implementation as close as possible to the systemd direction, by relying on USI images (so everything in a single binary), without pivoting to a second stage.
@poettering Isnt systemd-boot loading the drivers itself? I infered that by the location of the drivers (/EFI/systemd/drivers) ? In that case I would expect systemd-boot itself to measure the drivers in PCR11-15 like any other parts of the bootloader chain, otherwise waht prevents a malicious agent changing or loading an extra driver that breaks the Trusted Boot?
I.E. If we lock up partitions based on the measurements of the whole boot with a USI but drivers are NOT measured, then thats a big hole no?
I see, the FW MUST to store those measurements on PCR4 as per section 5.3 of the TCG EFI Platform Specification Version 1.22 (https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf)
Unfortunately systemd-measure does not measure those PCRs yet, so its not possible to link an encrypted partition to the full measurements chain if you expect to check the PCR11+PCR4+PCR7 (for secureboot)
Firmware specifications can vary much - especially in term of UEFI as it is quite open to vendors to implement it correctly - besides, I cannot find any information around UEFI drivers being measured by firmware, at least in the specs.
They are pretty much EFI programs, hence the same rules apply. Note that evertyhing sd-boot does here is to tell the firmware to load EFI drivers from disk too, not just from the usual efi vars DriverXXX. So if drivers really aren't authenticated on your system, then sd-boot is not really your problem, and could not possibly be the fix either: you firmware is just fucked and useless.
Is this something systemd-boot is interested in at some point? While I understand the expectation is the firmware to do measurements, the reality is that it really depends on vendor implementations. It's hard to build immutable systems that are built outside the target system programmatically as we cannot bind to lower PCRs and pre-calculate measurement outside of that specific device.
Do you have any proof/reprots that the measurements aren't done by some firmware?
systemd-pcrlock exists btw, it should help you automatically maintaining PCR policies on local measurements.
I really think that this could undermine the security aspects of Trusted Boot to some extents. Just for a little bit of context, for the Kairos project (https://github.com/kairos-io) we are trying to build against the Trusted Boot implementation as close as possible to the systemd direction, by relying on USI images (so everything in a single binary), without pivoting to a second stage.
So, if you can show me that this actually is a problem somewhere, we can certainly measure more stuff, but I'd really like to see this first.
I mean, there are other areas where we have reports that some firmwares don't measure what they should (i.e. SMBIOS), and I think we should just measure SMBIOS unconditionally before using it to deal with that problem. But to me it's news that there are firmwares that forget to measure the code they run. And unlike with SMBIOS (where we are consumers, and hence should measure before we do so, and the firmware usually doesn't consume it, but just provide it) there's the general problem that firmware will load drievrs from anywhere anyway because of the DriverXYZ efi var, and is both consumer and provider of these things, hence if we'd measure it in sd-boot/sd-stub then it's too late already...
@poettering Isnt systemd-boot loading the drivers itself? I infered that by the location of the drivers (
/EFI/systemd/drivers) ?
Depends on what you mean by "load". We just search for the driver EFI binaries, and then tell the firmware to load them. We don't parse any driver PE binaries or so, if that's what you mean by "loading".
In that case I would expect systemd-boot itself to measure the drivers in PCR11-15 like any other parts of the bootloader chain, otherwise waht prevents a malicious agent changing or loading an extra driver that breaks the Trusted Boot?
Well, we just tell firmware to run a binary basically, which firmware is expected to measure. It's not too different from chainloading an UKI PE binary, which after all is what sd-boot is about. There too we let firmware do the measurements.
I.E. If we lock up partitions based on the measurements of the whole boot with a USI but drivers are NOT measured, then thats a big hole no?
Yes, except that uefi firmware measures the binaries it loads. Otherwise sd-boot itself wouldn't show up in the measurements either, and hence there's no value in measuring anything else anymore.
Unfortunately systemd-measure does not measure those PCRs yet, so its not possible to link an encrypted partition to the full measurements chain if you expect to check the PCR11+PCR4+PCR7 (for secureboot)
That's what systemd-pcrlock exists for.
The idea is that systemd-pcrlock maintains a local policy in an NV index that covers the inherently local components of the system, while systemd-measure maintains a signed OS vendor policy that covers the OS vendor supplied components. (there's one thing missing currently though: that the policy maintained by systemd-pcrlock can reference a signed OS vendor policy, so that you get to use both together).
Yeah makes sense to me, EFI FW should be the one doing those measurements as systemd-boot just use the FW EFI facilities to load that, indeed.
Unfortunately systemd-measure does not measure those PCRs yet, so its not possible to link an encrypted partition to the full measurements chain if you expect to check the PCR11+PCR4+PCR7 (for secureboot)
That's what systemd-pcrlock exists for.
The idea is that systemd-pcrlock maintains a local policy in an NV index that covers the inherently local components of the system, while systemd-measure maintains a signed OS vendor policy that covers the OS vendor supplied components. (there's one thing missing currently though: that the policy maintained by systemd-pcrlock can reference a signed OS vendor policy, so that you get to use both together).
Yes, that sounds good, but indeed is not complete yet, so a measured UKI/USI can unlock properly a partition with those measurements, but we have no possibility to lock that into PCR4+7 as well right? So its possible to disable SecureBoot or load extra drivers into an installed system and that would still unlock the partition as the rest of the measurements would match (PCR11) which is a bit lacking for full Trusted Boot :D
In an ideal world that would all be matched, you get your UKI/USI measurements and the policy is linked to the PCR11+others like 4+7 (even more) to make sure that there is no entry point possible to a machine (no idsbaling secureboot, no loading extra drivers)
Yes, that sounds good, but indeed is not complete yet, so a measured UKI/USI can unlock properly a partition with those measurements, but we have no possibility to lock that into PCR4+7 as well right? So its possible to disable SecureBoot or load extra drivers into an installed system and that would still unlock the partition as the rest of the measurements would match (PCR11) which is a bit lacking for full Trusted Boot :D
Not sure if I understand correctly what you are asking, but systemd-pcrlock actually is flexible enough to lock down any PCR you'd like. And in fact I think that it would probably make sense to cover PCR 11 both by a vendor policy and by a local policy (i.e. lock it down "twice"), after all which OS vendor to use is a local choice too.
In an ideal world that would all be matched, you get your UKI/USI measurements and the policy is linked to the PCR11+others like 4+7 (even more) to make sure that there is no entry point possible to a machine (no idsbaling secureboot, no loading extra drivers)
not sure if understand the question here, but pcrlock actually covers PCR 7 just fine. You just need to do systemd-pcrlock lock-secureboot-policy and you are good to go. And if you do systemd-pcrlock lock-uki … and your pcrlock policy also includes PCR 11. and systemd-pcrlock lock-firmware-code will lock down firmware code and so on.
Anyway, I don't think there's anything actionable here. AFAIK firmwares measure drivers loaded that way, and unless there's proof otherwise I don#t think we should do anything on this.