Hi all On Thu, 25 Apr 2024 at 14:13, Lennart Poettering <mzxreary@xxxxxxxxxxx> wrote: > > On Do, 25.04.24 12:36, Ard Biesheuvel (ardb@xxxxxxxxxx) 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 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 Regards /Ilias > > Lennart > > -- > Lennart Poettering, Berlin
