Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Fri Apr 26, 2024 at 11:19 AM EEST, Mikko Rapeli wrote: > Hi, > > On Fri, Apr 26, 2024 at 10:40:20AM +0300, Jarkko Sakkinen wrote: > > On Fri Apr 26, 2024 at 10:35 AM EEST, Jarkko Sakkinen wrote: > > > On Thu Apr 25, 2024 at 5:01 PM EEST, Jarkko Sakkinen wrote: > > > > On Thu Apr 25, 2024 at 12:58 PM EEST, Lennart Poettering wrote: > > > > > General purpose distros typically don't build all TPM drivers into the > > > > > kernel, but ship some in the initrd instead. Then, udev is responsible > > > > > for iterating all buses/devices and auto-loading the necessary > > > > > drivers. Each loaded bus driver might make more devices available for > > > > > > > > I've had since day 0 that I've worked with TPM driver (i.e. since 2013 > > > > > > - had the opinion (typo) > > > > Tbh, I have zero idea what this discussion is about anyway because the > > original thread *was not* CC'd to linux-integrity and I'm not subscribed > > to linux-efi. So next time put all the relevant mailing lists. I.e. > > definitive NAK for this patch. > > Sorry for not including linux-integrity. I added maintainers and lists > proposed by scripts/get_maintainers.pl for the change which did not touch > drivers/char/tpm/ though TPM event log APIs are clearly there. > > The full thread starts from here: > > https://lore.kernel.org/all/20240422112711.362779-1-mikko.rap...@linaro.org/T/#u NP, just add CC to the next version. I'll download it and check through once bandwidth. > Cheers, > > -Mikko BR, Jarkko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi, On Fri, Apr 26, 2024 at 10:40:20AM +0300, Jarkko Sakkinen wrote: > On Fri Apr 26, 2024 at 10:35 AM EEST, Jarkko Sakkinen wrote: > > On Thu Apr 25, 2024 at 5:01 PM EEST, Jarkko Sakkinen wrote: > > > On Thu Apr 25, 2024 at 12:58 PM EEST, Lennart Poettering wrote: > > > > General purpose distros typically don't build all TPM drivers into the > > > > kernel, but ship some in the initrd instead. Then, udev is responsible > > > > for iterating all buses/devices and auto-loading the necessary > > > > drivers. Each loaded bus driver might make more devices available for > > > > > > I've had since day 0 that I've worked with TPM driver (i.e. since 2013 > > > > - had the opinion (typo) > > Tbh, I have zero idea what this discussion is about anyway because the > original thread *was not* CC'd to linux-integrity and I'm not subscribed > to linux-efi. So next time put all the relevant mailing lists. I.e. > definitive NAK for this patch. Sorry for not including linux-integrity. I added maintainers and lists proposed by scripts/get_maintainers.pl for the change which did not touch drivers/char/tpm/ though TPM event log APIs are clearly there. The full thread starts from here: https://lore.kernel.org/all/20240422112711.362779-1-mikko.rap...@linaro.org/T/#u Cheers, -Mikko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Fri Apr 26, 2024 at 10:35 AM EEST, Jarkko Sakkinen wrote: > On Thu Apr 25, 2024 at 5:01 PM EEST, Jarkko Sakkinen wrote: > > On Thu Apr 25, 2024 at 12:58 PM EEST, Lennart Poettering wrote: > > > General purpose distros typically don't build all TPM drivers into the > > > kernel, but ship some in the initrd instead. Then, udev is responsible > > > for iterating all buses/devices and auto-loading the necessary > > > drivers. Each loaded bus driver might make more devices available for > > > > I've had since day 0 that I've worked with TPM driver (i.e. since 2013 > > - had the opinion (typo) Tbh, I have zero idea what this discussion is about anyway because the original thread *was not* CC'd to linux-integrity and I'm not subscribed to linux-efi. So next time put all the relevant mailing lists. I.e. definitive NAK for this patch. BR, Jarkko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Thu Apr 25, 2024 at 5:01 PM EEST, Jarkko Sakkinen wrote: > On Thu Apr 25, 2024 at 12:58 PM EEST, Lennart Poettering wrote: > > General purpose distros typically don't build all TPM drivers into the > > kernel, but ship some in the initrd instead. Then, udev is responsible > > for iterating all buses/devices and auto-loading the necessary > > drivers. Each loaded bus driver might make more devices available for > > I've had since day 0 that I've worked with TPM driver (i.e. since 2013 - had the opinion (typo) BR, Jarkko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Thu Apr 25, 2024 at 12:58 PM EEST, Lennart Poettering wrote: > General purpose distros typically don't build all TPM drivers into the > kernel, but ship some in the initrd instead. Then, udev is responsible > for iterating all buses/devices and auto-loading the necessary > drivers. Each loaded bus driver might make more devices available for I've had since day 0 that I've worked with TPM driver (i.e. since 2013 or 2014) that module support should be removed. I've kept the module compilation only because huge turnback from the community. It does not make sense: 1. Because it makes sense as part of "TCB". 2. "TCB" is should in be vmlinux. 3. TPM is also a subsystem with other clients in the kernel. At minimum the main TPM driver should IMHO just in vmlinux e.g. because it is rare to see distro kernel with TPM enabled and IMA disabled, I don't know any. That said, I would not mind either if TPM subsystem drivers were only y/n *except* tpm_vtpm_proxy. BR, Jarkko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Thu Apr 25, 2024 at 11:56 AM EEST, Mikko Rapeli wrote: > 1) is there a TPM device Translates to "Does /sys/class/tpm/tpm0 exists?" TPM version can be determined with /sys/class/tpm/tpm0/tpm_version_major BR, Jarkko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Thu, 2024-04-25 at 15:36 +0200, Lennart Poettering wrote: > On Do, 25.04.24 14:47, Ilias Apalodimas (ilias.apalodi...@linaro.org) > wrote: > > > > Yeah, the physical address is of no interest to us. We just need > > > to > > > know the existance, and that independently of any actualy tpm > > > device > > > having shown up. i.e. existance of > > > /sys/kernel/security/tpm0/binary_bios_measurements would be good > > > enough for is if it was available without "tpm0" actually being > > > around... > > > > IIRC 'binary_bios_measurements' is only created after the TPM > > drivers > > probe the device, so that wouldn't work. > > Ard is right though the TPMEventLog is an EFI stub construct, so > > exposing this is Linux-specific (and stub-specific). > > The TPMFinalLog OTOH is described by the TCG spec so exposing that > > even using the address address would work for systemd > > Hmm, let me ask explicitly: is there any good reason for > 'binary_bios_measurements' being tied to specific TPM devices? i mean > it just exposes some firmware-provided memory area, no? Realistically, no. The current mechanism for exposing it in securityfs is tpm chip init, which means it can't appear before a TPM driver attaches, but there's no real reason why that has to be so. > So, if the answer to that question is "no", maybe we can just move > the file to some generic place that is not tied to "tpm0" being > around, and then make the current file a symlink to that new place > for compat? We could just keep it where it is. I don't believe a log ever appears at anything other than tpm0 because the event log securityfs attach is triggered on first tpm appearance, which has to be 0. So the name is purely conventional and could be hard coded. The eventlog code itself is all linked to the actual chip device (including some of the checks for event log type---we have to work with both 1.2 and 2.0), but it should be possible to get the information another way. James > i.e. /sys/kernel/security/tpm0/binary_bios_measurements could be a > symlink to → /sys/kernel/security/binary_bios_measurements and the > latter could be something the kernel always exposes, before any tpm > drivers are loaded?
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Do, 25.04.24 09:24, James Bottomley (james.bottom...@hansenpartnership.com) wrote: > On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote: > [...] > > General purpose distros typically don't build all TPM drivers into > > the kernel, but ship some in the initrd instead. Then, udev is > > responsible for iterating all buses/devices and auto-loading the > > necessary drivers. Each loaded bus driver might make more devices > > available for which more drivers then need to be loaded, and so on. > > Some of the busses are "slow" in the sense that we don't really know > > a precise time when we know that all devices have now shown up, there > > might always be slow devices that haven't popped up yet. Iterating > > through the entire tree of devices in sysfs is often quite slow in > > itself too, it's one of the most time consuming parts of the boot in > > fact. This all is done asynchronously hence: we > > enumerate/trigger/kmod all devices as quickly as we can, but we > > continue doing other stuff at the same time. > > So let me make a suggestion that you can use now. Since all you > currently care about is the EFI/ACPI device, there is always a single > sysfs entry that corresponds to that (so you shouldn't need the log > entry as an indicator): > > /sys/bus/acpi/devices/MSFT0101\:00 > > That link (or a kobject uevent if you prefer to look for that) will > always appear regardless of whether a driver has attached or not. When > the driver actually attaches, a driver/ directory will appear where the > link points. > > The device link is added when the acpi scan is initiated as a > subsys_initcall, which is before all the filesystem initcalls, so it > should run before the initrd is mounted. > > Is this enough for now and we can think about a more generic indicator > that all drivers have been probed later? That would only work on ACPI though, but on ACPI we already have a check that works? Or to say this differently: how is that different/better from the check that already exists in systemd, which looks for /sys/firmware/acpi/tables/TPM2? Lennart -- Lennart Poettering, Berlin
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi, On Thu, Apr 25, 2024 at 09:24:48AM -0400, James Bottomley wrote: > On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote: > [...] > > General purpose distros typically don't build all TPM drivers into > > the kernel, but ship some in the initrd instead. Then, udev is > > responsible for iterating all buses/devices and auto-loading the > > necessary drivers. Each loaded bus driver might make more devices > > available for which more drivers then need to be loaded, and so on. > > Some of the busses are "slow" in the sense that we don't really know > > a precise time when we know that all devices have now shown up, there > > might always be slow devices that haven't popped up yet. Iterating > > through the entire tree of devices in sysfs is often quite slow in > > itself too, it's one of the most time consuming parts of the boot in > > fact. This all is done asynchronously hence: we > > enumerate/trigger/kmod all devices as quickly as we can, but we > > continue doing other stuff at the same time. > > So let me make a suggestion that you can use now. Since all you > currently care about is the EFI/ACPI device, there is always a single > sysfs entry that corresponds to that (so you shouldn't need the log > entry as an indicator): > > /sys/bus/acpi/devices/MSFT0101\:00 > > That link (or a kobject uevent if you prefer to look for that) will > always appear regardless of whether a driver has attached or not. When > the driver actually attaches, a driver/ directory will appear where the > link points. > > The device link is added when the acpi scan is initiated as a > subsys_initcall, which is before all the filesystem initcalls, so it > should run before the initrd is mounted. > > Is this enough for now and we can think about a more generic indicator > that all drivers have been probed later? This covers EFI ACPI devices but not devices without ACPI. Some boards have the TPM device data in devicetree. Some boards have a firmware TPM which is not listed in devicetree but is detected at runtime once optee drivers, tee-supplicant, etc have loaded. Based on the comments here, I could propose a v2 with TPMFinalLog based sysfs file which is empty but existence of the file shows to systemd that EFI firmware used a TPM device and that can queue in the normal ACPI, devicetree or other mechanisms of detecting the real TPM device, loading drivers and possibly needed userspace components like tee-supplicant for optee and fTPM. I don't know how non-EFI firmware could be supported, unless they show the ACPI TPM entry. Cheers, -Mikko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Do, 25.04.24 14:47, Ilias Apalodimas (ilias.apalodi...@linaro.org) wrote: > > Yeah, the physical address is of no interest to us. We just need to > > know the existance, and that independently of any actualy tpm device > > having shown up. i.e. existance of > > /sys/kernel/security/tpm0/binary_bios_measurements would be good > > enough for is if it was available without "tpm0" actually being > > around... > > IIRC 'binary_bios_measurements' is only created after the TPM drivers > probe the device, so that wouldn't work. > Ard is right though the TPMEventLog is an EFI stub construct, so > exposing this is Linux-specific (and stub-specific). > The TPMFinalLog OTOH is described by the TCG spec so exposing that > even using the address address would work for systemd Hmm, let me ask explicitly: is there any good reason for 'binary_bios_measurements' being tied to specific TPM devices? i mean it just exposes some firmware-provided memory area, no? So, if the answer to that question is "no", maybe we can just move the file to some generic place that is not tied to "tpm0" being around, and then make the current file a symlink to that new place for compat? i.e. /sys/kernel/security/tpm0/binary_bios_measurements could be a symlink to → /sys/kernel/security/binary_bios_measurements and the latter could be something the kernel always exposes, before any tpm drivers are loaded? Lennart -- Lennart Poettering, Berlin
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote: [...] > General purpose distros typically don't build all TPM drivers into > the kernel, but ship some in the initrd instead. Then, udev is > responsible for iterating all buses/devices and auto-loading the > necessary drivers. Each loaded bus driver might make more devices > available for which more drivers then need to be loaded, and so on. > Some of the busses are "slow" in the sense that we don't really know > a precise time when we know that all devices have now shown up, there > might always be slow devices that haven't popped up yet. Iterating > through the entire tree of devices in sysfs is often quite slow in > itself too, it's one of the most time consuming parts of the boot in > fact. This all is done asynchronously hence: we > enumerate/trigger/kmod all devices as quickly as we can, but we > continue doing other stuff at the same time. So let me make a suggestion that you can use now. Since all you currently care about is the EFI/ACPI device, there is always a single sysfs entry that corresponds to that (so you shouldn't need the log entry as an indicator): /sys/bus/acpi/devices/MSFT0101\:00 That link (or a kobject uevent if you prefer to look for that) will always appear regardless of whether a driver has attached or not. When the driver actually attaches, a driver/ directory will appear where the link points. The device link is added when the acpi scan is initiated as a subsys_initcall, which is before all the filesystem initcalls, so it should run before the initrd is mounted. Is this enough for now and we can think about a more generic indicator that all drivers have been probed later? James
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi all On Thu, 25 Apr 2024 at 14:13, Lennart Poettering wrote: > > On Do, 25.04.24 12:36, Ard Biesheuvel (a...@kernel.org) wrote: > > > > systemd these days makes use of the TPM — if available — for various > > > purposes, such as disk encryption, measuring boot phases and system > > > identity and various other things. Now, for the purpose of disk > > > encryption, we need to wait for two things: the hard drive, and the > > > TPM to be probed/driver loaded/accessible. /etc/fstab tells us pretty > > > explicitly what bloock device to wait for, hence it's easy. But > > > waiting for a TPM is harder: we might need it for disk encryption, but > > > we don't know right-away if there actually *is* a TPM device to show > > > up, and hence don't know whether to wait for it or not. > > > > > > > I take it this means that the LUKS metadata lacks a 'this key is > > sealed into the TPM' bit? > > Well, it does carry that info. But this is of no relevance > really. typically luks has multiple keys enrolled, and which slot(s) to > use is really up to the moment of invocation, depending on what is available. > > moreover, i used disk encryption as one example, but we have more > users of TPM. for example we measure early in the initrd that we are > now in the initd, and when we leave the initrd we measure that we are > now gone. we also have a tool that sets up the TPM SRK. All that stuff > is supposed to be run if a TPM is available, but delayed just enough > until the TPM actually shows up, but no more. So for all of that stuff > we must have a way to delay tings correctly. > > > So exposing the physical address of the TPM event log is probably not > > what we want here. > > > > Note that the TPM event log table is a Linux/efistub construct, > > whereas the TPM final log table actually comes from the firmware > > directly. So the former only exists if the EFI stub executed first, > > and managed to invoke the TCG protocol etc. OTOH, the TPM final log is > > TPM2 only, so it doesn't exist on TPM 1.2 > > (side note: in systemd we do not care about tpm 1.2 anymore, we only > support tpm2, and treat systems with just tpm 1.2 like systems that > have no tpm). > > > Another thing we need to consider is TDX, which exposes a pseudo-TPM > > which does not support sealing, along with a CC protocol similar to > > the TCG2 protocol. This code will use the event log infrastructure as > > well: there are discussions going on at the moment whether we can > > improve the way these protocols are combined. > > The way the delay for a tpm device is actually implemented in systemd > is somewhat generic: there's a target unit called > "tpm2.target". Typically we just delay its activation until a > /dev/tpmrm0 device shows up, if the firmware check suggested that. But > you could also stuff all kinds of other stuff before that. For exampe, > we could also delay it until some userspace service is running that > turns the local security tech into a "fake" tpm device or similar. So > from our side it's entirely pluggable already, and supports other ways > to synchronize properly on a TPM being available, people can plug in > whatever they need there for the synchronization. > > However, our primary focus is to cover nicely the typical/generic > systems that have a discrete TPM or ftpm that just needs some generic > driver probing/loading to be available. > > Or in other words: i am fully aware that a tpm-like device can be > provided by various means. For now, with this firmware flag file thing > we primarily care about the simple case where it's just driver loading > that we need to do. > > > So we should define a scope here: > > - do we need TPM1.2 support? > > For our systemd usecase, that's a clear no. > > > - do we need non-EFI boot support? > > My own focus is EFI. systemd supports non-EFI of course. If people > care about non-EFI I am sure they'd be thankful if we could provide a > similar automatism > > > - do we need to do anything in particular for FDE on TDX, which has a > > TPM event log but no TPM is likely to appear. > > I'd ignore that for now. And if they provide a software tpm-like device > eventually they just have to plug in the service that provides it > before tpm2.target and be done with it. I think we have an acceptable > approach for that already. > > > I am fine with adding a sysfs node under /sys/firmware/efi that > > exposes some of this information, e.g., > > linux_efi_tpm_eventlog::version, but not the physical address of the > > table. > > Yeah, the physical address is of no interest to us. We just need to > know the existance, and that independently of any actualy tpm device > having shown up. i.e. existance of > /sys/kernel/security/tpm0/binary_bios_measurements would be good > enough for is if it was available without "tpm0" actually being > around... IIRC 'binary_bios_measurements' is only created after the TPM drivers probe the device, so that wouldn't work. Ard is right though the TPMEventLog is an EFI
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Do, 25.04.24 12:36, Ard Biesheuvel (a...@kernel.org) wrote: > > systemd these days makes use of the TPM — if available — for various > > purposes, such as disk encryption, measuring boot phases and system > > identity and various other things. Now, for the purpose of disk > > encryption, we need to wait for two things: the hard drive, and the > > TPM to be probed/driver loaded/accessible. /etc/fstab tells us pretty > > explicitly what bloock device to wait for, hence it's easy. But > > waiting for a TPM is harder: we might need it for disk encryption, but > > we don't know right-away if there actually *is* a TPM device to show > > up, and hence don't know whether to wait for it or not. > > > > I take it this means that the LUKS metadata lacks a 'this key is > sealed into the TPM' bit? Well, it does carry that info. But this is of no relevance really. typically luks has multiple keys enrolled, and which slot(s) to use is really up to the moment of invocation, depending on what is available. moreover, i used disk encryption as one example, but we have more users of TPM. for example we measure early in the initrd that we are now in the initd, and when we leave the initrd we measure that we are now gone. we also have a tool that sets up the TPM SRK. All that stuff is supposed to be run if a TPM is available, but delayed just enough until the TPM actually shows up, but no more. So for all of that stuff we must have a way to delay tings correctly. > So exposing the physical address of the TPM event log is probably not > what we want here. > > Note that the TPM event log table is a Linux/efistub construct, > whereas the TPM final log table actually comes from the firmware > directly. So the former only exists if the EFI stub executed first, > and managed to invoke the TCG protocol etc. OTOH, the TPM final log is > TPM2 only, so it doesn't exist on TPM 1.2 (side note: in systemd we do not care about tpm 1.2 anymore, we only support tpm2, and treat systems with just tpm 1.2 like systems that have no tpm). > Another thing we need to consider is TDX, which exposes a pseudo-TPM > which does not support sealing, along with a CC protocol similar to > the TCG2 protocol. This code will use the event log infrastructure as > well: there are discussions going on at the moment whether we can > improve the way these protocols are combined. The way the delay for a tpm device is actually implemented in systemd is somewhat generic: there's a target unit called "tpm2.target". Typically we just delay its activation until a /dev/tpmrm0 device shows up, if the firmware check suggested that. But you could also stuff all kinds of other stuff before that. For exampe, we could also delay it until some userspace service is running that turns the local security tech into a "fake" tpm device or similar. So from our side it's entirely pluggable already, and supports other ways to synchronize properly on a TPM being available, people can plug in whatever they need there for the synchronization. However, our primary focus is to cover nicely the typical/generic systems that have a discrete TPM or ftpm that just needs some generic driver probing/loading to be available. Or in other words: i am fully aware that a tpm-like device can be provided by various means. For now, with this firmware flag file thing we primarily care about the simple case where it's just driver loading that we need to do. > So we should define a scope here: > - do we need TPM1.2 support? For our systemd usecase, that's a clear no. > - do we need non-EFI boot support? My own focus is EFI. systemd supports non-EFI of course. If people care about non-EFI I am sure they'd be thankful if we could provide a similar automatism > - do we need to do anything in particular for FDE on TDX, which has a > TPM event log but no TPM is likely to appear. I'd ignore that for now. And if they provide a software tpm-like device eventually they just have to plug in the service that provides it before tpm2.target and be done with it. I think we have an acceptable approach for that already. > I am fine with adding a sysfs node under /sys/firmware/efi that > exposes some of this information, e.g., > linux_efi_tpm_eventlog::version, but not the physical address of the > table. Yeah, the physical address is of no interest to us. We just need to know the existance, and that independently of any actualy tpm device having shown up. i.e. existance of /sys/kernel/security/tpm0/binary_bios_measurements would be good enough for is if it was available without "tpm0" actually being around... Lennart -- Lennart Poettering, Berlin
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi Lennart, Thanks to you and Mikko for providing this background. On Thu, 25 Apr 2024 at 11:59, Lennart Poettering wrote: > > On Mi, 24.04.24 19:15, Ard Biesheuvel (a...@kernel.org) wrote: > > > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > > > > all these in is possible but a bit ugly. systemd recently > > > > > > > > gained support for a specific tpm2.target which makes TPM > > > > > > > > support modular and also works with kernel modules for some TPM > > > > > > > > use cases but not rootfs encryption. > > > > > > > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > > > > various boards is visible in devicetree but not as ACPI table > > > > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > > > > firmware measurement via > > > > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > > > > . > > > > > > > > > > > > > > One corner case worth noting here is that scanning the device > > > > > > > tree won't always work for non-ACPI systems... The reason is that > > > > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > > > > entry, since OP-TEE can discover the device dynamically and > > > > > > > doesn't always rely on a DT entry. > > > > > > > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > > > > automatically means a TPM will be there, but it seems that > > > > > > > systemd already relies on that and it does solve the problem we > > > > > > > have. > > > > > > > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > > > > not asked as clearly as it could be is: since all the TPM devices > > > > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > > > > ready quite early, should we simply be auto loading the TPM drivers > > > > > > earlier? > > > > > > > > > > This would be an elegant way to solve this and on top of that, we > > > > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > > > > But to answer that we need more feedback from systemd. What 'earlier' > > > > > means? Autload it from the kernel before we go into launching the > > > > > initrd? > > > > > > > > Right, so this is another timing problem: we can't autoload modules > > > > *before* they appear in the filesystem and presumably they're on the > > > > initrd, so auto loading must be post initrd mount (and init execution) > > > > but otherwise quite early? > > > > > > Exactly. But is that enough? > > General purpose distros typically don't build all TPM drivers into the > kernel, but ship some in the initrd instead. Then, udev is responsible > for iterating all buses/devices and auto-loading the necessary > drivers. Each loaded bus driver might make more devices available for > which more drivers then need to be loaded, and so on. Some of the > busses are "slow" in the sense that we don't really know a precise > time when we know that all devices have now shown up, there might > always be slow devices that haven't popped up yet. Iterating through > the entire tree of devices in sysfs is often quite slow in itself too, > it's one of the most time consuming parts of the boot in fact. This > all is done asynchronously hence: we enumerate/trigger/kmod all > devices as quickly as we can, but we continue doing other stuff at the > same time. > > Of course that means that other stuff sometimes has to *wait* for > devices to show up. For example, if a harddisk shall be mounted, it > needs to be found/probed/kmod'ed first. Hence that's what we do: the > fscking/mounting of a file system is delayed exactly as long as it > takes for the block device it is for to show up. > > systemd these days makes use of the TPM — if available — for various > purposes, such as disk encryption, measuring boot phases and system > identity and various other things. Now, for the purpose of disk > encryption, we need to wait for two things: the hard drive, and the > TPM to be probed/driver loaded/accessible. /etc/fstab tells us pretty > explicitly what bloock device to wait for, hence it's easy. But > waiting for a TPM is harder: we might need it for disk encryption, but > we don't know right-away if there actually *is* a TPM device to show > up, and hence don't know whether to wait for it or not. > I take it this means that the LUKS metadata lacks a 'this key is sealed into the TPM' bit? Could you elaborate a bit on how the early boot code manages this? ... > > Exposing random firmware assets directly to user space to make
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Mi, 24.04.24 19:15, Ard Biesheuvel (a...@kernel.org) wrote: > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > > > all these in is possible but a bit ugly. systemd recently > > > > > > > gained support for a specific tpm2.target which makes TPM > > > > > > > support modular and also works with kernel modules for some TPM > > > > > > > use cases but not rootfs encryption. > > > > > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > > > various boards is visible in devicetree but not as ACPI table > > > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > > > firmware measurement via > > > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > > > . > > > > > > > > > > > > One corner case worth noting here is that scanning the device > > > > > > tree won't always work for non-ACPI systems... The reason is that > > > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > > > entry, since OP-TEE can discover the device dynamically and > > > > > > doesn't always rely on a DT entry. > > > > > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > > > automatically means a TPM will be there, but it seems that > > > > > > systemd already relies on that and it does solve the problem we > > > > > > have. > > > > > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > > > not asked as clearly as it could be is: since all the TPM devices > > > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > > > ready quite early, should we simply be auto loading the TPM drivers > > > > > earlier? > > > > > > > > This would be an elegant way to solve this and on top of that, we > > > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > > > But to answer that we need more feedback from systemd. What 'earlier' > > > > means? Autload it from the kernel before we go into launching the > > > > initrd? > > > > > > Right, so this is another timing problem: we can't autoload modules > > > *before* they appear in the filesystem and presumably they're on the > > > initrd, so auto loading must be post initrd mount (and init execution) > > > but otherwise quite early? > > > > Exactly. But is that enough? General purpose distros typically don't build all TPM drivers into the kernel, but ship some in the initrd instead. Then, udev is responsible for iterating all buses/devices and auto-loading the necessary drivers. Each loaded bus driver might make more devices available for which more drivers then need to be loaded, and so on. Some of the busses are "slow" in the sense that we don't really know a precise time when we know that all devices have now shown up, there might always be slow devices that haven't popped up yet. Iterating through the entire tree of devices in sysfs is often quite slow in itself too, it's one of the most time consuming parts of the boot in fact. This all is done asynchronously hence: we enumerate/trigger/kmod all devices as quickly as we can, but we continue doing other stuff at the same time. Of course that means that other stuff sometimes has to *wait* for devices to show up. For example, if a harddisk shall be mounted, it needs to be found/probed/kmod'ed first. Hence that's what we do: the fscking/mounting of a file system is delayed exactly as long as it takes for the block device it is for to show up. systemd these days makes use of the TPM — if available — for various purposes, such as disk encryption, measuring boot phases and system identity and various other things. Now, for the purpose of disk encryption, we need to wait for two things: the hard drive, and the TPM to be probed/driver loaded/accessible. /etc/fstab tells us pretty explicitly what bloock device to wait for, hence it's easy. But waiting for a TPM is harder: we might need it for disk encryption, but we don't know right-away if there actually *is* a TPM device to show up, and hence don't know whether to wait for it or not. In systemd we hence check early if firmware reported that it measured something into a TPM during early boot. If not, then we have no measured boot, and we don't have to wait for the TPM. (Of course, there could possibly be a TPM that the firmware didn't use, but even if, there's no real point in waiting for it, since a TPM is not that interesting if your firmware didn't protect the boot with it/filled the PCRs with data). If however we see that firmware measured something into the TPM, then we deduce from that
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi, On Wed, Apr 24, 2024 at 07:15:35PM +0200, Ard Biesheuvel wrote: > On Mon, 22 Apr 2024 at 17:22, Ilias Apalodimas > wrote: > > > > On Mon, 22 Apr 2024 at 17:31, James Bottomley > > wrote: > > > > > > On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > > > > Hi James > > > > > > > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > > > > wrote: > > > > > > > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > > > > Hi all, > > > > > > > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley > > > > > > > wrote: > > > > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > > > > Userspace needs to know if TPM kernel drivers need to be > > > > > > > > > loaded and related services started early in the boot if > > > > > > > > > TPM device is used and available. > > > > > > > > > > > > > > > > This says what but not why. We already have module > > > > > > > > autoloading that works correctly for TPM devices, so why is > > > > > > > > this needed? > > > > > > > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > > > > driver needs to be present *before* any filesystem, including > > > > > > > > the one the TPM modules would be on, is mounted so executions > > > > > > > > can be measured into IMA (meaning that if you use IMA the TPM > > > > > > > > drivers must be built in) but this sounds to be something > > > > > > > > different. However, because of the IMA problem, most > > > > > > > > distributions don't end up compiling TPM drivers as modules > > > > > > > > anyway. > > > > > > > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > > > > > > > Yes, ealier is the problem. In my specific testing case the > > > > > > > machine is qemu arm64 with swtpm with EFI firmware for secure > > > > > > > boot and TPM support. > > > > > > > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log > > > > > > > is > > > > > > > available on this machine and a bunch of other arm64 boards. > > > > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > > > all these in is possible but a bit ugly. systemd recently > > > > > > > gained support for a specific tpm2.target which makes TPM > > > > > > > support modular and also works with kernel modules for some TPM > > > > > > > use cases but not rootfs encryption. > > > > > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > > > various boards is visible in devicetree but not as ACPI table > > > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > > > firmware measurement via > > > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > > > . > > > > > > > > > > > > One corner case worth noting here is that scanning the device > > > > > > tree won't always work for non-ACPI systems... The reason is that > > > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > > > entry, since OP-TEE can discover the device dynamically and > > > > > > doesn't always rely on a DT entry. > > > > > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > > > automatically means a TPM will be there, but it seems that > > > > > > systemd already relies on that and it does solve the problem we > > > > > > have. > > > > > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > > > not asked as clearly as it could be is: since all the TPM devices > > > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > > > ready quite early, should we simply be auto loading the TPM drivers > > > > > earlier? > > > > > > > > This would be an elegant way to solve this and on top of that, we > > > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > > > But to answer that we need more feedback from systemd. What 'earlier' > > > > means? Autload it from the kernel before we go into launching the > > > > initrd? > > > > > > Right, so this is another timing problem: we can't autoload modules > > > *before* they appear in the filesystem and presumably they're on the > > > initrd, so auto loading must be post initrd mount (and init execution) > > > but otherwise quite early? > > > > Exactly. But is that enough? > > > > > > > > This might be quite a bit
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Mon, 22 Apr 2024 at 17:22, Ilias Apalodimas wrote: > > On Mon, 22 Apr 2024 at 17:31, James Bottomley > wrote: > > > > On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > > > Hi James > > > > > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > > > wrote: > > > > > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > > > Hi all, > > > > > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > > > > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley > > > > > > wrote: > > > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > > > Userspace needs to know if TPM kernel drivers need to be > > > > > > > > loaded and related services started early in the boot if > > > > > > > > TPM device is used and available. > > > > > > > > > > > > > > This says what but not why. We already have module > > > > > > > autoloading that works correctly for TPM devices, so why is > > > > > > > this needed? > > > > > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > > > driver needs to be present *before* any filesystem, including > > > > > > > the one the TPM modules would be on, is mounted so executions > > > > > > > can be measured into IMA (meaning that if you use IMA the TPM > > > > > > > drivers must be built in) but this sounds to be something > > > > > > > different. However, because of the IMA problem, most > > > > > > > distributions don't end up compiling TPM drivers as modules > > > > > > > anyway. > > > > > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > > > > > Yes, ealier is the problem. In my specific testing case the > > > > > > machine is qemu arm64 with swtpm with EFI firmware for secure > > > > > > boot and TPM support. > > > > > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log > > > > > > is > > > > > > available on this machine and a bunch of other arm64 boards. > > > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > > all these in is possible but a bit ugly. systemd recently > > > > > > gained support for a specific tpm2.target which makes TPM > > > > > > support modular and also works with kernel modules for some TPM > > > > > > use cases but not rootfs encryption. > > > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > > various boards is visible in devicetree but not as ACPI table > > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > > firmware measurement via > > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > > . > > > > > > > > > > One corner case worth noting here is that scanning the device > > > > > tree won't always work for non-ACPI systems... The reason is that > > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > > entry, since OP-TEE can discover the device dynamically and > > > > > doesn't always rely on a DT entry. > > > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > > automatically means a TPM will be there, but it seems that > > > > > systemd already relies on that and it does solve the problem we > > > > > have. > > > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > > not asked as clearly as it could be is: since all the TPM devices > > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > > ready quite early, should we simply be auto loading the TPM drivers > > > > earlier? > > > > > > This would be an elegant way to solve this and on top of that, we > > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > > But to answer that we need more feedback from systemd. What 'earlier' > > > means? Autload it from the kernel before we go into launching the > > > initrd? > > > > Right, so this is another timing problem: we can't autoload modules > > *before* they appear in the filesystem and presumably they're on the > > initrd, so auto loading must be post initrd mount (and init execution) > > but otherwise quite early? > > Exactly. But is that enough? > > > > > This might be quite a bit of work. Logically, just moving the matching > > and loading code earlier might work, but we used to have a > > load_default_modules() at the end of init/main.c and it got removed > > (because it only eventually loaded elevator modules) everything is now > > loaded in it's
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Mon, 22 Apr 2024 at 17:31, James Bottomley wrote: > > On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > > Hi James > > > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > > wrote: > > > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > > Hi all, > > > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley > > > > > wrote: > > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > > Userspace needs to know if TPM kernel drivers need to be > > > > > > > loaded and related services started early in the boot if > > > > > > > TPM device is used and available. > > > > > > > > > > > > This says what but not why. We already have module > > > > > > autoloading that works correctly for TPM devices, so why is > > > > > > this needed? > > > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > > driver needs to be present *before* any filesystem, including > > > > > > the one the TPM modules would be on, is mounted so executions > > > > > > can be measured into IMA (meaning that if you use IMA the TPM > > > > > > drivers must be built in) but this sounds to be something > > > > > > different. However, because of the IMA problem, most > > > > > > distributions don't end up compiling TPM drivers as modules > > > > > > anyway. > > > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > > > Yes, ealier is the problem. In my specific testing case the > > > > > machine is qemu arm64 with swtpm with EFI firmware for secure > > > > > boot and TPM support. > > > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log > > > > > is > > > > > available on this machine and a bunch of other arm64 boards. > > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > all these in is possible but a bit ugly. systemd recently > > > > > gained support for a specific tpm2.target which makes TPM > > > > > support modular and also works with kernel modules for some TPM > > > > > use cases but not rootfs encryption. > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > various boards is visible in devicetree but not as ACPI table > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > firmware measurement via > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > . > > > > > > > > One corner case worth noting here is that scanning the device > > > > tree won't always work for non-ACPI systems... The reason is that > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > entry, since OP-TEE can discover the device dynamically and > > > > doesn't always rely on a DT entry. > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > automatically means a TPM will be there, but it seems that > > > > systemd already relies on that and it does solve the problem we > > > > have. > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > not asked as clearly as it could be is: since all the TPM devices > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > ready quite early, should we simply be auto loading the TPM drivers > > > earlier? > > > > This would be an elegant way to solve this and on top of that, we > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > But to answer that we need more feedback from systemd. What 'earlier' > > means? Autload it from the kernel before we go into launching the > > initrd? > > Right, so this is another timing problem: we can't autoload modules > *before* they appear in the filesystem and presumably they're on the > initrd, so auto loading must be post initrd mount (and init execution) > but otherwise quite early? Exactly. But is that enough? > > This might be quite a bit of work. Logically, just moving the matching > and loading code earlier might work, but we used to have a > load_default_modules() at the end of init/main.c and it got removed > (because it only eventually loaded elevator modules) everything is now > loaded in it's various init routines, so to get, say, TPM ACPI modules > loaded earlier, we'd have to run the ACPI device matching code earlier > and so on for every other subsystem ... Being the devil's advocate here and as I stated I don't love this but ... The kernel isn't
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi, On Mon, Apr 22, 2024 at 04:54:26PM +0300, Ilias Apalodimas wrote: > Hi James > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > wrote: > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > Hi all, > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > wrote: > > > > > > > > Hi, > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley wrote: > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > Userspace needs to know if TPM kernel drivers need to be loaded > > > > > > and related services started early in the boot if TPM device > > > > > > is used and available. > > > > > > > > > > This says what but not why. We already have module autoloading > > > > > that works correctly for TPM devices, so why is this needed? > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > driver needs to be present *before* any filesystem, including the > > > > > one the TPM modules would be on, is mounted so executions can be > > > > > measured into IMA (meaning that if you use IMA the TPM drivers > > > > > must be built in) but this sounds to be something different. > > > > > However, because of the IMA problem, most distributions don't end > > > > > up compiling TPM drivers as modules anyway. > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > Yes, ealier is the problem. In my specific testing case the machine > > > > is qemu arm64 with swtpm with EFI firmware for secure boot and TPM > > > > support. > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log is > > > > available on this machine and a bunch of other arm64 boards. > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > Different boards use different TPM HW and drivers so compiling all > > > > these in is possible but a bit ugly. systemd recently gained > > > > support for a specific tpm2.target which makes TPM support modular > > > > and also works with kernel modules for some TPM use cases but not > > > > rootfs encryption. > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > various boards is visible in devicetree but not as ACPI table > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via firmware > > > > measurement via /sys/kernel/security/tpm0/binary_bios_measurements > > > > . > > > > > > One corner case worth noting here is that scanning the device tree > > > won't always work for non-ACPI systems... The reason is that a > > > firmware TPM (running in OP-TEE) might or might not have a DT entry, > > > since OP-TEE can discover the device dynamically and doesn't always > > > rely on a DT entry. > > > > > > I don't particularly love the idea that an EventLog existence > > > automatically means a TPM will be there, but it seems that systemd > > > already relies on that and it does solve the problem we have. > > > > Well, quite. That's why the question I was interested in, perhaps not > > asked as clearly as it could be is: since all the TPM devices rely on > > discovery mechanisms like ACPI or DT or the like which are ready quite > > early, should we simply be auto loading the TPM drivers earlier? > > This would be an elegant way to solve this and on top of that, we have > a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > But to answer that we need more feedback from systemd. What 'earlier' > means? Autload it from the kernel before we go into launching the > initrd? This is sort of what already happens, but the question is when does init/systemd wait for the TPM device discovery and setup of related service so that rootfs can be mounted? Currently the answer is, for device auto discover: when ACPI TPM2 table exists or TPM kernel driver interface for firmware measurement is available. Or as policy, when the kernel command line includes something or services in initramfs are hard coded. Parsing devicetree is really hard in userspace but it may contain the TPM details. But the TPM can also be on some other discoverable bus, firmware TPM optee trusted application. These both get discovered via the TPM Event Log if firmware has TPM support on the arm64 boards we have. Cheers, -Mikko
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > Hi James > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > wrote: > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > Hi all, > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley > > > > wrote: > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > Userspace needs to know if TPM kernel drivers need to be > > > > > > loaded and related services started early in the boot if > > > > > > TPM device is used and available. > > > > > > > > > > This says what but not why. We already have module > > > > > autoloading that works correctly for TPM devices, so why is > > > > > this needed? > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > driver needs to be present *before* any filesystem, including > > > > > the one the TPM modules would be on, is mounted so executions > > > > > can be measured into IMA (meaning that if you use IMA the TPM > > > > > drivers must be built in) but this sounds to be something > > > > > different. However, because of the IMA problem, most > > > > > distributions don't end up compiling TPM drivers as modules > > > > > anyway. > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > Yes, ealier is the problem. In my specific testing case the > > > > machine is qemu arm64 with swtpm with EFI firmware for secure > > > > boot and TPM support. > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log > > > > is > > > > available on this machine and a bunch of other arm64 boards. > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > [ 0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > all these in is possible but a bit ugly. systemd recently > > > > gained support for a specific tpm2.target which makes TPM > > > > support modular and also works with kernel modules for some TPM > > > > use cases but not rootfs encryption. > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > various boards is visible in devicetree but not as ACPI table > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > firmware measurement via > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > . > > > > > > One corner case worth noting here is that scanning the device > > > tree won't always work for non-ACPI systems... The reason is that > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > entry, since OP-TEE can discover the device dynamically and > > > doesn't always rely on a DT entry. > > > > > > I don't particularly love the idea that an EventLog existence > > > automatically means a TPM will be there, but it seems that > > > systemd already relies on that and it does solve the problem we > > > have. > > > > Well, quite. That's why the question I was interested in, perhaps > > not asked as clearly as it could be is: since all the TPM devices > > rely on discovery mechanisms like ACPI or DT or the like which are > > ready quite early, should we simply be auto loading the TPM drivers > > earlier? > > This would be an elegant way to solve this and on top of that, we > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > But to answer that we need more feedback from systemd. What 'earlier' > means? Autload it from the kernel before we go into launching the > initrd? Right, so this is another timing problem: we can't autoload modules *before* they appear in the filesystem and presumably they're on the initrd, so auto loading must be post initrd mount (and init execution) but otherwise quite early? This might be quite a bit of work. Logically, just moving the matching and loading code earlier might work, but we used to have a load_default_modules() at the end of init/main.c and it got removed (because it only eventually loaded elevator modules) everything is now loaded in it's various init routines, so to get, say, TPM ACPI modules loaded earlier, we'd have to run the ACPI device matching code earlier and so on for every other subsystem ... James
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Hi James On Mon, 22 Apr 2024 at 16:38, James Bottomley wrote: > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > Hi all, > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > wrote: > > > > > > Hi, > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley wrote: > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > Userspace needs to know if TPM kernel drivers need to be loaded > > > > > and related services started early in the boot if TPM device > > > > > is used and available. > > > > > > > > This says what but not why. We already have module autoloading > > > > that works correctly for TPM devices, so why is this needed? > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > driver needs to be present *before* any filesystem, including the > > > > one the TPM modules would be on, is mounted so executions can be > > > > measured into IMA (meaning that if you use IMA the TPM drivers > > > > must be built in) but this sounds to be something different. > > > > However, because of the IMA problem, most distributions don't end > > > > up compiling TPM drivers as modules anyway. > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > Yes, ealier is the problem. In my specific testing case the machine > > > is qemu arm64 with swtpm with EFI firmware for secure boot and TPM > > > support. > > > > > > Firmware uses TPM and does measurements and thus TPM event log is > > > available on this machine and a bunch of other arm64 boards. > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > [0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > Different boards use different TPM HW and drivers so compiling all > > > these in is possible but a bit ugly. systemd recently gained > > > support for a specific tpm2.target which makes TPM support modular > > > and also works with kernel modules for some TPM use cases but not > > > rootfs encryption. > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > various boards is visible in devicetree but not as ACPI table > > > entries. systemd currently detect TPM2 support either via ACPI > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via firmware > > > measurement via /sys/kernel/security/tpm0/binary_bios_measurements > > > . > > > > One corner case worth noting here is that scanning the device tree > > won't always work for non-ACPI systems... The reason is that a > > firmware TPM (running in OP-TEE) might or might not have a DT entry, > > since OP-TEE can discover the device dynamically and doesn't always > > rely on a DT entry. > > > > I don't particularly love the idea that an EventLog existence > > automatically means a TPM will be there, but it seems that systemd > > already relies on that and it does solve the problem we have. > > Well, quite. That's why the question I was interested in, perhaps not > asked as clearly as it could be is: since all the TPM devices rely on > discovery mechanisms like ACPI or DT or the like which are ready quite > early, should we simply be auto loading the TPM drivers earlier? This would be an elegant way to solve this and on top of that, we have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. But to answer that we need more feedback from systemd. What 'earlier' means? Autload it from the kernel before we go into launching the initrd? Thanks /Ilias > James >
Re: [PATCH] efi: expose TPM event log to userspace via sysfs
On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > Hi all, > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > wrote: > > > > Hi, > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley wrote: > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > Userspace needs to know if TPM kernel drivers need to be loaded > > > > and related services started early in the boot if TPM device > > > > is used and available. > > > > > > This says what but not why. We already have module autoloading > > > that works correctly for TPM devices, so why is this needed? > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > driver needs to be present *before* any filesystem, including the > > > one the TPM modules would be on, is mounted so executions can be > > > measured into IMA (meaning that if you use IMA the TPM drivers > > > must be built in) but this sounds to be something different. > > > However, because of the IMA problem, most distributions don't end > > > up compiling TPM drivers as modules anyway. > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > Yes, ealier is the problem. In my specific testing case the machine > > is qemu arm64 with swtpm with EFI firmware for secure boot and TPM > > support. > > > > Firmware uses TPM and does measurements and thus TPM event log is > > available on this machine and a bunch of other arm64 boards. > > Visible in early boot dmesg as TPMEventLog lines like: > > > > [ 0.00] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > Different boards use different TPM HW and drivers so compiling all > > these in is possible but a bit ugly. systemd recently gained > > support for a specific tpm2.target which makes TPM support modular > > and also works with kernel modules for some TPM use cases but not > > rootfs encryption. > > > > In my test case we have a kernel+initramfs uki binary which is > > loaded by EFI firmware as a secure boot binary. TPM support on > > various boards is visible in devicetree but not as ACPI table > > entries. systemd currently detect TPM2 support either via ACPI > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via firmware > > measurement via /sys/kernel/security/tpm0/binary_bios_measurements > > . > > One corner case worth noting here is that scanning the device tree > won't always work for non-ACPI systems... The reason is that a > firmware TPM (running in OP-TEE) might or might not have a DT entry, > since OP-TEE can discover the device dynamically and doesn't always > rely on a DT entry. > > I don't particularly love the idea that an EventLog existence > automatically means a TPM will be there, but it seems that systemd > already relies on that and it does solve the problem we have. Well, quite. That's why the question I was interested in, perhaps not asked as clearly as it could be is: since all the TPM devices rely on discovery mechanisms like ACPI or DT or the like which are ready quite early, should we simply be auto loading the TPM drivers earlier? James
