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
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 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
gs: 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 that Linux will probably find the device too sooner or later, we just need to give the udev enumerate/trigger/kmod logic enough time. And so we tell the disk encryption stuff to wait for a TPM to show up before we continue. This works quite well in the x86/acpi/uefi world. There, we check for the efi tpm event log + the ACPI TPM table as indication whether TPM was used by firmware. Note that we are not interested in the *contents* of the log or the table to determine if we shall wait for a tpm device, we just care about the *existence*. i.e. it's two access() calls that check if the two things exist in sysfs. On ACPI-less arm platforms this check doesn't work. And we are looking for a sensible replacement: i.e. something that tells us that the firmware found, initialized, and measured stuff into a TPM and that is enough for us to assume that sooner or later it will also be probed and be accessible in Linux/udev/…, too. This check is done very very early in userspace (early initrd), at a moment in time where no devices have been probed yet. How precisely we do the check is up for discussion. All we care about is an answer to the question "Did firmware find and make use/measure into a TPM device? yes/no". And we want to be able to answer that question very early in userspace, without having to actually probe hardware/busses/drivers/…. And yes, the test we implemented on x86/acpu/uefi might actually come to the wrong conclusion, because Linux might lack a driver for a TPM the firmware supports. But right now there are few reports this is actually a problem, Linux TPM support seems to be quite OK IRL. Moreover, there's an override via the kernel cmdline (systemd.tpm2_wait=0) for the cases where the logic fails. > What I would like to know is which API systemd is attempting to use, > and which -apparently- may never become available if no TPM is exposed > by the kernel. We want a trivial check whether it's likely Linux is going to expose a TPM device eventually. And yes, as mentioned, there might be cases where Linux lacks a driver for something the firmware support. But as long as this is not the common case we are good. > Ideally, we should be able to take inspiration from the probe deferral > work, and return -EAGAIN to convey that it is too early to signal > either success or permanent failure. We need an early check, so that we can dealy FDE setup, that we can delay our first boot phase measurements and so on. An kernel interface that just tells us "we don't have a tpm yet, we might have one one day, or not, we don't know yet" is useless to us. > Exposing random firmware assets directly to user space to make guesses > about this doesn't seem like a very robust approach to this issue. If you give us a generic flag file that says "firmware found and used a tpm" somewhere in sysfs that abstracts the details how it detects that is enough for us. i.e. i don't care if the kenrel abstracts this or if we do more explicit checks in userspace. All i care is that it's just a few access(F_OK) checks away for us. Lennart -- Lennart Poettering, Berlin
Re: [PATCH] systemd: mount the EFI variable filesystem
On Sat, 27.10.12 11:23, Lee, Chun-Yi (joeyli.ker...@gmail.com) wrote: > Add efivarfs to the mount_table in mount-setup.c, so the EFI variable > filesystem will be mounted when systemd executed. > > The EFI variable filesystem will merge in v3.7 or v3.8 linux kernel. I can't really test this, but looks reasonably simple, and I assume this has been tested, so I merged this. Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add syste-firmware-efi-efivars.mount for support automount EFI variable filesystem
On Wed, 24.10.12 18:42, Lee, Chun-Yi (joeyli.ker...@gmail.com) wrote: > Add units/sys-firmware-efi-efivars.mount rule for support automount > EFI variable filesystem Good in principle, but as Kay mentioned we probably should not expose this as units, but just mount it from PID1's C code. More specifically add it to the table in src/core/mount-setup.c, but make sure to set the "fatal" bool in the table to false for this entry, to clarify that this is not a reason to fail. You probably also want to add the kmod to the table in src/core/kmod-setup.c since the mount point is not available if the kmod is not loaded. Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
