| Message ID | 20240128212532.2754325-1-sameo@rivosinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tsm: Runtime measurement registers ABI | expand |
On Sun Jan 28, 2024 at 11:25 PM EET, Samuel Ortiz wrote: > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V > CoVE) provide their guests with a set of measurements registers that can > be extended at runtime, i.e. after the initial, host-initiated > measurements of the TVM are finalized. Those runtime measurement > registers (RTMR) are isolated from the host accessible ones but TSMs > include them in their signed attestation reports. Please expand "TSM" acronym and explain what it is. > All architectures supporting RTMRs expose a similar interface to their Please expand RTMR *everywhere* ot "measurement registers". It is totally useless terminology. > TVMs: An extension command/call that takes a measurement value and an What is TVM? > RTMR index to extend it with, and a readback command for reading an RTMR > value back (taking an RTMR index as an argument as well). This patch series > builds an architecture agnostic, configfs-based ABI for userspace to extend > and read RTMR values back. It extends the current TSM ops structure and > each confidential computing architecture can implement this extension to > provide RTMR support. This patch set should simplify its gibberish terminology to common language. BR, Jarkko
On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: > All architectures supporting RTMRs expose a similar interface to > their TVMs: An extension command/call that takes a measurement value > and an RTMR index to extend it with, and a readback command for > reading an RTMR value back (taking an RTMR index as an argument as > well). This patch series builds an architecture agnostic, configfs- > based ABI for userspace to extend and read RTMR values back. It > extends the current TSM ops structure and each confidential computing > architecture can implement this extension to provide RTMR support. What's the actual use case for this? At the moment the TPM PCRs only provide a read interface to userspace (via /sys/class/tpm/tpmX/pcr- shaY/Z) and don't have any extension ability becuase nothing in userspace currently extends them. The only current runtime use for TPM PCRs is IMA, which is in-kernel (and which this patch doesn't enable). Without the ability to log, this interface is unusable anyway, but even with that it's not clear that you need the ability separately to extend PCRs because the extension and log entry should be done atomically to prevent the log going out of sync with the PCRs, so it would seem a log first interface would be the correct way of doing this rather than a PCR first one. James
On 2/2/24 12:24 AM, James Bottomley wrote: > On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: >> All architectures supporting RTMRs expose a similar interface to >> their TVMs: An extension command/call that takes a measurement value >> and an RTMR index to extend it with, and a readback command for >> reading an RTMR value back (taking an RTMR index as an argument as >> well). This patch series builds an architecture agnostic, configfs- >> based ABI for userspace to extend and read RTMR values back. It >> extends the current TSM ops structure and each confidential computing >> architecture can implement this extension to provide RTMR support. > What's the actual use case for this? At the moment the TPM PCRs only > provide a read interface to userspace (via /sys/class/tpm/tpmX/pcr- > shaY/Z) and don't have any extension ability becuase nothing in > userspace currently extends them. > > The only current runtime use for TPM PCRs is IMA, which is in-kernel > (and which this patch doesn't enable). > > Without the ability to log, this interface is unusable anyway, but even > with that it's not clear that you need the ability separately to extend > PCRs because the extension and log entry should be done atomically to > prevent the log going out of sync with the PCRs, so it would seem a log > first interface would be the correct way of doing this rather than a > PCR first one. > > James > > While we clearly need to cover PCR-like usages, I think Confidential Computing affords usages that go beyond TPM. For example, Attested Containers [1] (and similar explorations in CNCF Confidential Containers [2]) extends the measurement chain into the guest. There, a trusted agent measures container images, and extends an RTMR with those measurements. Particularly in the case of containers, the existing runtime infrastructure is user mode oriented. However the generalization here is in providing a mechanism to strongly identify an application or behavior provided by the TVM. Less concretely, I think this is an area for developer creativity. Attestation is one of the main APIs that CC gives application developers and these runtime extendable fields provide a further degree of creativity. [1] ACON https://github.com/intel/acon [2] CoCo https://github.com/confidential-containers/guest-components/commit/3c75201a8ba0327fb41b68b7e1521ff517e3ca9f Regards, Dan
On Fri, 2024-02-02 at 17:07 -0600, Dan Middleton wrote: > > On 2/2/24 12:24 AM, James Bottomley wrote: > > On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: > > > All architectures supporting RTMRs expose a similar interface to > > > their TVMs: An extension command/call that takes a measurement > > > value and an RTMR index to extend it with, and a readback command > > > for reading an RTMR value back (taking an RTMR index as an > > > argument as well). This patch series builds an architecture > > > agnostic, configfs-based ABI for userspace to extend and read > > > RTMR values back. It extends the current TSM ops structure and > > > each confidential computing architecture can implement this > > > extension to provide RTMR support. > > What's the actual use case for this? At the moment the TPM PCRs > > only provide a read interface to userspace (via > > /sys/class/tpm/tpmX/pcr-shaY/Z) and don't have any extension > > ability becuase nothing in userspace currently extends them. > > > > The only current runtime use for TPM PCRs is IMA, which is in- > > kernel (and which this patch doesn't enable). > > > > Without the ability to log, this interface is unusable anyway, but > > even with that it's not clear that you need the ability separately > > to extend PCRs because the extension and log entry should be done > > atomically to prevent the log going out of sync with the PCRs, so > > it would seem a log first interface would be the correct way of > > doing this rather than a PCR first one. > > > > James > > > > > > While we clearly need to cover PCR-like usages, I think Confidential > Computing affords usages that go beyond TPM. Well, don't get me wrong, I think the ability to create non repudiable log entries from userspace is very useful. However, I think the proposed ABI is wrong: it should take the log entry (which will contain the PCR number and the hash) then do the extension and add it to the log so we get the non-repudiable verifiability. This should work equally with TPM and RTMR (and anything else). The issue, I suppose, is what log format? The TCG has one which is extensible and IMA uses a similar but different binary log format. > For example, Attested Containers [1] (and similar explorations in > CNCF Confidential Containers [2]) extends the measurement chain into > the guest. There, a trusted agent measures container images, and > extends an RTMR with those measurements. Particularly in the case of > containers, the existing runtime infrastructure is user mode > oriented. However the generalization here is in providing a mechanism > to strongly identify an application or behavior provided by the TVM. There's a similar proposal for Keylime which was demo'd at Plumbers last year, except it uses IMA to measure the container so you only have to trust the kernel: https://lpc.events/event/17/contributions/1571/ > Less concretely, I think this is an area for developer creativity. > Attestation is one of the main APIs that CC gives application > developers and > these runtime extendable fields provide a further degree of > creativity. > > [1] ACON https://github.com/intel/acon Just on this, lest we repeat the errors of the past (and believe me there was a time people thought that simply extending TPM PCRs without log entries was the way to do measurements), if you're extending a PCR like entity you also need a log entry to tell people who come after you what you've done. Even in the one ephemeral VM per pod kata use case (with RTMRs local to the VM), you'll still likely be starting several sidecars and if you don't have a log to tell you the order you measured the containers deriving the RTMR value is a combinatoric explosion. James
On 2/2/24 10:03 PM, James Bottomley wrote: > On Fri, 2024-02-02 at 17:07 -0600, Dan Middleton wrote: >> On 2/2/24 12:24 AM, James Bottomley wrote: >>> On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: >>>> All architectures supporting RTMRs expose a similar interface to >>>> their TVMs: An extension command/call that takes a measurement >>>> value and an RTMR index to extend it with, and a readback command >>>> for reading an RTMR value back (taking an RTMR index as an >>>> argument as well). This patch series builds an architecture >>>> agnostic, configfs-based ABI for userspace to extend and read >>>> RTMR values back. It extends the current TSM ops structure and >>>> each confidential computing architecture can implement this >>>> extension to provide RTMR support. >>> What's the actual use case for this? At the moment the TPM PCRs >>> only provide a read interface to userspace (via >>> /sys/class/tpm/tpmX/pcr-shaY/Z) and don't have any extension >>> ability becuase nothing in userspace currently extends them. >>> >>> The only current runtime use for TPM PCRs is IMA, which is in- >>> kernel (and which this patch doesn't enable). >>> >>> Without the ability to log, this interface is unusable anyway, but >>> even with that it's not clear that you need the ability separately >>> to extend PCRs because the extension and log entry should be done >>> atomically to prevent the log going out of sync with the PCRs, so >>> it would seem a log first interface would be the correct way of >>> doing this rather than a PCR first one. >>> >>> James >>> >>> >> While we clearly need to cover PCR-like usages, I think Confidential >> Computing affords usages that go beyond TPM. > Well, don't get me wrong, I think the ability to create non repudiable > log entries from userspace is very useful. However, I think the > proposed ABI is wrong: it should take the log entry (which will contain > the PCR number and the hash) then do the extension and add it to the > log so we get the non-repudiable verifiability. This should work > equally with TPM and RTMR (and anything else). Maybe I misunderstood your comments, but I am not sure why the user ABI needs to change? I agree that logging after extension is the right approach. But, IMO, it should be owned by the back end TSM vendor drivers. The user ABI should just pass the digest and RTMR index. > > The issue, I suppose, is what log format? The TCG has one which is > extensible and IMA uses a similar but different binary log format. TDX uses EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 log format. I think SEV is the same. https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#virtual-platform-cc-event-log > >> For example, Attested Containers [1] (and similar explorations in >> CNCF Confidential Containers [2]) extends the measurement chain into >> the guest. There, a trusted agent measures container images, and >> extends an RTMR with those measurements. Particularly in the case of >> containers, the existing runtime infrastructure is user mode >> oriented. However the generalization here is in providing a mechanism >> to strongly identify an application or behavior provided by the TVM. > There's a similar proposal for Keylime which was demo'd at Plumbers > last year, except it uses IMA to measure the container so you only have > to trust the kernel: > > https://lpc.events/event/17/contributions/1571/ > >> Less concretely, I think this is an area for developer creativity. >> Attestation is one of the main APIs that CC gives application >> developers and >> these runtime extendable fields provide a further degree of >> creativity. >> >> [1] ACON https://github.com/intel/acon > Just on this, lest we repeat the errors of the past (and believe me > there was a time people thought that simply extending TPM PCRs without > log entries was the way to do measurements), if you're extending a PCR > like entity you also need a log entry to tell people who come after you > what you've done. Even in the one ephemeral VM per pod kata use case > (with RTMRs local to the VM), you'll still likely be starting several > sidecars and if you don't have a log to tell you the order you measured > the containers deriving the RTMR value is a combinatoric explosion. > > James > >
On Fri, 2024-02-02 at 23:13 -0800, Kuppuswamy Sathyanarayanan wrote: > > On 2/2/24 10:03 PM, James Bottomley wrote: > > On Fri, 2024-02-02 at 17:07 -0600, Dan Middleton wrote: > > > On 2/2/24 12:24 AM, James Bottomley wrote: > > > > On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: > > > > > All architectures supporting RTMRs expose a similar interface > > > > > to > > > > > their TVMs: An extension command/call that takes a > > > > > measurement > > > > > value and an RTMR index to extend it with, and a readback > > > > > command > > > > > for reading an RTMR value back (taking an RTMR index as an > > > > > argument as well). This patch series builds an architecture > > > > > agnostic, configfs-based ABI for userspace to extend and read > > > > > RTMR values back. It extends the current TSM ops structure > > > > > and > > > > > each confidential computing architecture can implement this > > > > > extension to provide RTMR support. > > > > What's the actual use case for this? At the moment the TPM > > > > PCRs > > > > only provide a read interface to userspace (via > > > > /sys/class/tpm/tpmX/pcr-shaY/Z) and don't have any extension > > > > ability becuase nothing in userspace currently extends them. > > > > > > > > The only current runtime use for TPM PCRs is IMA, which is in- > > > > kernel (and which this patch doesn't enable). > > > > > > > > Without the ability to log, this interface is unusable anyway, > > > > but > > > > even with that it's not clear that you need the ability > > > > separately > > > > to extend PCRs because the extension and log entry should be > > > > done > > > > atomically to prevent the log going out of sync with the PCRs, > > > > so > > > > it would seem a log first interface would be the correct way of > > > > doing this rather than a PCR first one. > > > > > > > > James > > > > > > > > > > > While we clearly need to cover PCR-like usages, I think > > > Confidential > > > Computing affords usages that go beyond TPM. > > Well, don't get me wrong, I think the ability to create non > > repudiable > > log entries from userspace is very useful. However, I think the > > proposed ABI is wrong: it should take the log entry (which will > > contain > > the PCR number and the hash) then do the extension and add it to > > the > > log so we get the non-repudiable verifiability. This should work > > equally with TPM and RTMR (and anything else). > > Maybe I misunderstood your comments, but I am not sure why > the user ABI needs to change? Well, there is no ABI currently, so I'm saying get it right before there is one. > I agree that logging after extension is the right approach. But, > IMO, it should be owned by the back end TSM vendor drivers. The user > ABI should just pass the digest and RTMR index. Well, lets wind back to the assumptions about the log. The current convention from IMA and Measured Boot is that the log is managed by the kernel. Given the potential problems with timing and serialization (which can cause log mismatches) it would make sense for this ABI also to have a kernel backed log (probably a new one from the other two). If you have a kernel backed log, the ABI for extending it should be where you get the PCR extensions from, that way nothing can go wrong. An API to extend the PCRs separately will only cause pain for people who get it wrong (and lead to ordering issues if more than one thing wants to add to the log, which they will do because neither the TPM nor the RTMRs have enough registers to do one per process that wants to use it if this becomes popular). James
On 2/3/2024 2:27 AM, James Bottomley wrote: > On Fri, 2024-02-02 at 23:13 -0800, Kuppuswamy Sathyanarayanan wrote: >> >> On 2/2/24 10:03 PM, James Bottomley wrote: >>> On Fri, 2024-02-02 at 17:07 -0600, Dan Middleton wrote: >>>> On 2/2/24 12:24 AM, James Bottomley wrote: >>>>> On Sun, 2024-01-28 at 22:25 +0100, Samuel Ortiz wrote: >>>>>> All architectures supporting RTMRs expose a similar interface >>>>>> to >>>>>> their TVMs: An extension command/call that takes a >>>>>> measurement >>>>>> value and an RTMR index to extend it with, and a readback >>>>>> command >>>>>> for reading an RTMR value back (taking an RTMR index as an >>>>>> argument as well). This patch series builds an architecture >>>>>> agnostic, configfs-based ABI for userspace to extend and read >>>>>> RTMR values back. It extends the current TSM ops structure >>>>>> and >>>>>> each confidential computing architecture can implement this >>>>>> extension to provide RTMR support. >>>>> What's the actual use case for this? At the moment the TPM >>>>> PCRs >>>>> only provide a read interface to userspace (via >>>>> /sys/class/tpm/tpmX/pcr-shaY/Z) and don't have any extension >>>>> ability becuase nothing in userspace currently extends them. >>>>> >>>>> The only current runtime use for TPM PCRs is IMA, which is in- >>>>> kernel (and which this patch doesn't enable). >>>>> >>>>> Without the ability to log, this interface is unusable anyway, >>>>> but >>>>> even with that it's not clear that you need the ability >>>>> separately >>>>> to extend PCRs because the extension and log entry should be >>>>> done >>>>> atomically to prevent the log going out of sync with the PCRs, >>>>> so >>>>> it would seem a log first interface would be the correct way of >>>>> doing this rather than a PCR first one. >>>>> >>>>> James >>>>> >>>>> >>>> While we clearly need to cover PCR-like usages, I think >>>> Confidential >>>> Computing affords usages that go beyond TPM. >>> Well, don't get me wrong, I think the ability to create non >>> repudiable >>> log entries from userspace is very useful. However, I think the >>> proposed ABI is wrong: it should take the log entry (which will >>> contain >>> the PCR number and the hash) then do the extension and add it to >>> the >>> log so we get the non-repudiable verifiability. This should work >>> equally with TPM and RTMR (and anything else). >> >> Maybe I misunderstood your comments, but I am not sure why >> the user ABI needs to change? > > Well, there is no ABI currently, so I'm saying get it right before > there is one. > >> I agree that logging after extension is the right approach. But, >> IMO, it should be owned by the back end TSM vendor drivers. The user >> ABI should just pass the digest and RTMR index. > > Well, lets wind back to the assumptions about the log. The current > convention from IMA and Measured Boot is that the log is managed by the > kernel. Given the potential problems with timing and serialization > (which can cause log mismatches) it would make sense for this ABI also > to have a kernel backed log (probably a new one from the other two). I'm not familiar with existing TPM code. Per https://elixir.free-electrons.com/linux/latest/source/drivers/char/tpm/tpm-interface.c#L314, tpm_pcr_extend() doesn't seem to take/log the actual event, but only extends the PCR. IMA seems to maintain the measurement list/log by itself. Am I right? If so, why do we want logging to be part of TSM here? For measured boots, I think UEFI BIOS has already maintained a log so what's needed here is just to expose the log somewhere in sysfs. IMHO, I don't think logging is even necessary because everything in the boot flow is static, hence a relying party can simply compare measurement registers against known good values without looking at any log. But please correct me if I have missed anything. > If you have a kernel backed log, the ABI for extending it should be > where you get the PCR extensions from, that way nothing can go wrong. > An API to extend the PCRs separately will only cause pain for people > who get it wrong (and lead to ordering issues if more than one thing > wants to add to the log, which they will do because neither the TPM nor > the RTMRs have enough registers to do one per process that wants to use > it if this becomes popular). > There's an easy way to solve the synchronization problem in user mode by applying flock() on the log file - i.e., a process can extend a measurement register only when holding an exclusive lock on the corresponding log file. A possible drawback is it'd allow a malicious process to starve all other processes by holding the lock forever, or to mess up the log file content intentionally. But that shouldn't be a practical problem because the existence of such malicious processes would have rendered the CVM untrustworthy anyway - i.e., should the CVM still be able to generate a valid attestation, that would only lead to a distrust decision by any sane relying party. IMHO, if something can be easily solved in user mode, probably it shouldn't be solved in kernel mode. > James >
On Tue, 2024-02-06 at 00:34 -0800, Xing, Cedric wrote: [...] > I'm not familiar with existing TPM code. Per > https://elixir.free-electrons.com/linux/latest/source/drivers/char/tpm/tpm-interface.c#L314 > , > tpm_pcr_extend() doesn't seem to take/log the actual event, but only > extends the PCR. That's the low level code we build on. The TPM doesn't maintain a log at all, just the measuring entity. > IMA seems to maintain the measurement list/log by itself. It does, yes. > Am I right? If so, why do we want logging to be part of TSM > here? Well, as I said above: without a log you have a combinatoric explosion of events that lead to the PCR value. > For measured boots, I think UEFI BIOS has already maintained a log so > what's needed here is just to expose the log somewhere in sysfs. > IMHO, I don't think logging is even necessary because everything in > the boot flow is static, hence a relying party can simply compare > measurement registers against known good values without looking at > any log. But please correct me if I have missed anything. Without the log the UEFI boot flow is way too brittle because measurements aren't actually static and without knowing what happened you can't reproduce the PCR value. It was actually the earliest insight from the keylime project that it couldn't just define state by PCR values and had to parse the log instead. > > If you have a kernel backed log, the ABI for extending it should be > > where you get the PCR extensions from, that way nothing can go > > wrong. An API to extend the PCRs separately will only cause pain > > for people who get it wrong (and lead to ordering issues if more > > than one thing wants to add to the log, which they will do because > > neither the TPM nor the RTMRs have enough registers to do one per > > process that wants to use it if this becomes popular). > > > There's an easy way to solve the synchronization problem in user mode > by applying flock() on the log file - i.e., a process can extend a > measurement register only when holding an exclusive lock on the > corresponding log file. Which would be where exactly? and owned by whom? > A possible drawback is it'd allow a malicious > process to starve all other processes by holding the lock forever, or > to mess up the log file content intentionally. But that shouldn't be > a practical problem because the existence of such malicious processes > would have rendered the CVM untrustworthy anyway - i.e., should the > CVM still be able to generate a valid attestation, that would only > lead to a distrust decision by any sane relying party. > > IMHO, if something can be easily solved in user mode, probably it > shouldn't be solved in kernel mode. There isn't really anything more complex about an interface that takes a log entry, and does the record an extend, than an interface which takes a PCR extension value. So best practice would say that you should create the ABI that you can't get wrong (log and record) rather than creating one that causes additional problems for userspace. James
James Bottomley wrote: > There isn't really anything more complex about an interface that takes > a log entry, and does the record an extend, than an interface which > takes a PCR extension value. So best practice would say that you > should create the ABI that you can't get wrong (log and record) rather > than creating one that causes additional problems for userspace. Agree, there's no need for the kernel to leave deliberately pointy edges for userspace to trip over. Cedric, almost every time we, kernel community, build an interface where userspace says "trust us, we know what we are doing" it inevitably results later in "whoops, turns out it would have helped if the kernel enforced structure here". So the log ABI adds that structure for the primary use cases.
On 2/6/2024 6:02 PM, Dan Williams wrote: > James Bottomley wrote: >> There isn't really anything more complex about an interface that takes >> a log entry, and does the record an extend, than an interface which >> takes a PCR extension value. So best practice would say that you >> should create the ABI that you can't get wrong (log and record) rather >> than creating one that causes additional problems for userspace. > > Agree, there's no need for the kernel to leave deliberately pointy edges > for userspace to trip over. > > Cedric, almost every time we, kernel community, build an interface where > userspace says "trust us, we know what we are doing" it inevitably > results later in "whoops, turns out it would have helped if the kernel > enforced structure here". So the log ABI adds that structure for the > primary use cases. Dan, I agree with your statement generally. But with the precedent of TPM module not maintaining a log, I just wonder if the addition of log would cause problems or force more changes to existing usages than necessary. For example, IMA has its own log and if changed to use RTMR, how would those 2 logs interoperate? We would also need to decide on a log format that can accommodate all applications.
On 2/7/24 12:16 PM, Xing, Cedric wrote: > On 2/6/2024 6:02 PM, Dan Williams wrote: >> James Bottomley wrote: >>> There isn't really anything more complex about an interface that takes >>> a log entry, and does the record an extend, than an interface which >>> takes a PCR extension value. So best practice would say that you >>> should create the ABI that you can't get wrong (log and record) rather >>> than creating one that causes additional problems for userspace. >> >> Agree, there's no need for the kernel to leave deliberately pointy edges >> for userspace to trip over. >> >> Cedric, almost every time we, kernel community, build an interface where >> userspace says "trust us, we know what we are doing" it inevitably >> results later in "whoops, turns out it would have helped if the kernel >> enforced structure here". So the log ABI adds that structure for the >> primary use cases. > > Dan, I agree with your statement generally. But with the precedent of TPM module not maintaining a log, I just wonder if the addition of log would cause problems or force more changes to existing usages than necessary. For example, IMA has its own log and if changed to use RTMR, how would those 2 logs interoperate? We would also need to decide on a log format that can accommodate all applications. IIUC, CC event logging in firmware uses TCG2 format. Since IMA internally uses TPM calls, I assume it also uses the TCG2 format. I think we can follow the same format for RTMR extension. I am wondering where will the event log be stored? Is it in the log_area region of CCEL table?
On Wed, 2024-02-07 at 13:08 -0800, Kuppuswamy Sathyanarayanan wrote: > > On 2/7/24 12:16 PM, Xing, Cedric wrote: > > On 2/6/2024 6:02 PM, Dan Williams wrote: > > > James Bottomley wrote: > > > > There isn't really anything more complex about an interface > > > > that takes a log entry, and does the record an extend, than an > > > > interface which takes a PCR extension value. So best practice > > > > would say that you should create the ABI that you can't get > > > > wrong (log and record) rather than creating one that causes > > > > additional problems for userspace. > > > > > > Agree, there's no need for the kernel to leave deliberately > > > pointy edges for userspace to trip over. > > > > > > Cedric, almost every time we, kernel community, build an > > > interface where userspace says "trust us, we know what we are > > > doing" it inevitably results later in "whoops, turns out it would > > > have helped if the kernel enforced structure here". So the log > > > ABI adds that structure for the primary use cases. > > > > Dan, I agree with your statement generally. But with the precedent > > of TPM module not maintaining a log, I just wonder if the addition > > of log would cause problems or force more changes to existing > > usages than necessary. For example, IMA has its own log and if > > changed to use RTMR, how would those 2 logs interoperate? We would > > also need to decide on a log format that can accommodate all > > applications. > > > IIUC, CC event logging in firmware uses TCG2 format. Since IMA > internally uses TPM calls, I assume it also uses the TCG2 format. I > think we can follow the same format for RTMR extension. Just to correct this: IMA uses its own log format, but I think this was a mistake long ago and the new log should use TCG2 format so all the tools know how to parse it. > I am wondering where will the event log be stored? Is it in the > log_area region of CCEL table? IMA stores its log in kernel memory and makes it visible in securityfs (in the smae place as the measured boot log). Since this interface is using configfs, that's where I'd make the log visible. Just to add a note about how UEFI works: the measured boot log is effectively copied into kernel memory because the UEFI memory it once occupied is freed after exit boot services, so no UEFI interface will suffice for the log location. I'd make the file exporting it root owned but probably readable by only the people who can also extend it (presumably enforced by group?). James
James Bottomley wrote: > On Wed, 2024-02-07 at 13:08 -0800, Kuppuswamy Sathyanarayanan wrote: > > > > On 2/7/24 12:16 PM, Xing, Cedric wrote: > > > On 2/6/2024 6:02 PM, Dan Williams wrote: > > > > James Bottomley wrote: > > > > > There isn't really anything more complex about an interface > > > > > that takes a log entry, and does the record an extend, than an > > > > > interface which takes a PCR extension value. So best practice > > > > > would say that you should create the ABI that you can't get > > > > > wrong (log and record) rather than creating one that causes > > > > > additional problems for userspace. > > > > > > > > Agree, there's no need for the kernel to leave deliberately > > > > pointy edges for userspace to trip over. > > > > > > > > Cedric, almost every time we, kernel community, build an > > > > interface where userspace says "trust us, we know what we are > > > > doing" it inevitably results later in "whoops, turns out it would > > > > have helped if the kernel enforced structure here". So the log > > > > ABI adds that structure for the primary use cases. > > > > > > Dan, I agree with your statement generally. But with the precedent > > > of TPM module not maintaining a log, I just wonder if the addition > > > of log would cause problems or force more changes to existing > > > usages than necessary. For example, IMA has its own log and if > > > changed to use RTMR, how would those 2 logs interoperate? We would > > > also need to decide on a log format that can accommodate all > > > applications. > > > > > > IIUC, CC event logging in firmware uses TCG2 format. Since IMA > > internally uses TPM calls, I assume it also uses the TCG2 format. I > > think we can follow the same format for RTMR extension. > > Just to correct this: IMA uses its own log format, but I think this was > a mistake long ago and the new log should use TCG2 format so all the > tools know how to parse it. Is this a chance to nudge IMA towards a standard log format? In other words, one of the goals alongside userspace consumers of the RTMR log would be for IMA to support it as well as an alternate in-kernel backend next to TPM. IMA-over-TPM continues with its current format, IMA-over-RTMR internally unifies with the log format that is shared with RTMR-user-ABI. ...but be warned the above is a comment from someone who knows nothing about IMA internals, just reacting to the comment. > > I am wondering where will the event log be stored? Is it in the > > log_area region of CCEL table? > > IMA stores its log in kernel memory and makes it visible in securityfs > (in the smae place as the measured boot log). Since this interface is > using configfs, that's where I'd make the log visible. > > Just to add a note about how UEFI works: the measured boot log is > effectively copied into kernel memory because the UEFI memory it once > occupied is freed after exit boot services, so no UEFI interface will > suffice for the log location. > > I'd make the file exporting it root owned but probably readable by only > the people who can also extend it (presumably enforced by group?). I assume EFI copying into kernel memory is ok because that log has a limited number of entries. If this RTMR log gets large I assume it needs some way cull entries that have been moved to storage. Maybe this is a problem IMA has already solved.
On 2/9/2024 12:58 PM, Dan Williams wrote: > James Bottomley wrote: >> Just to correct this: IMA uses its own log format, but I think this was >> a mistake long ago and the new log should use TCG2 format so all the >> tools know how to parse it. > > Is this a chance to nudge IMA towards a standard log format? In other > words, one of the goals alongside userspace consumers of the RTMR log > would be for IMA to support it as well as an alternate in-kernel backend > next to TPM. IMA-over-TPM continues with its current format, > IMA-over-RTMR internally unifies with the log format that is shared with > RTMR-user-ABI. > I'm not a TCG expert. As far as I know, https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf defines the event types for TCG2 logs for firmware uses only. I cannot find a spec that defines event types for OS or applications. We may reuse the firmware event types for Linux but I doubt they can accommodate IMA. IMHO, we don't have to follow TCG2 format because TDX is never TPM, nor are any other TEEs that support runtime measurements. The existing TCG2 format looks to me somewhat like ASN.1 - well defined but schema is needed to decode. In contrast, JSON is a lot more popular than ASN.1 nowadays because it's human readable and doesn't require a schema. I just wonder if we should introduce a text based log format. We could make the log a text file, in which each line is an event record and the digest of the line is extended to the specified runtime measurement register. The content of each line could be free-form at the ABI level, but we can still recommend a convention for applications - e.g., the first word/column must be an URL for readers to find out the format/syntax of the rest of the line. Thoughts? > ...but be warned the above is a comment from someone who knows nothing > about IMA internals, just reacting to the comment. > > >>> I am wondering where will the event log be stored? Is it in the >>> log_area region of CCEL table? >> >> IMA stores its log in kernel memory and makes it visible in securityfs >> (in the smae place as the measured boot log). Since this interface is >> using configfs, that's where I'd make the log visible. >> >> Just to add a note about how UEFI works: the measured boot log is >> effectively copied into kernel memory because the UEFI memory it once >> occupied is freed after exit boot services, so no UEFI interface will >> suffice for the log location. >> >> I'd make the file exporting it root owned but probably readable by only >> the people who can also extend it (presumably enforced by group?). > > I assume EFI copying into kernel memory is ok because that log has a > limited number of entries. If this RTMR log gets large I assume it needs > some way cull entries that have been moved to storage. Maybe this is a > problem IMA has already solved. We don't have to, and are also not supposed to I guess, append to the log generated by BIOS. The kernel can start a new log, and potentially in a different format. I think the BIOS log is exposed via securityfs today. Am I correct? For the new TEE measurement log, I don't think it has to be collocated with the BIOS log, because TEEs are never TPMs.
On Mon, 2024-02-12 at 23:36 -0800, Xing, Cedric wrote: > On 2/9/2024 12:58 PM, Dan Williams wrote: > > James Bottomley wrote: > > > Just to correct this: IMA uses its own log format, but I think > > > this was a mistake long ago and the new log should use TCG2 > > > format so all the tools know how to parse it. > > > > Is this a chance to nudge IMA towards a standard log format? In > > other words, one of the goals alongside userspace consumers of the > > RTMR log would be for IMA to support it as well as an alternate in- > > kernel backend next to TPM. IMA-over-TPM continues with its current > > format, IMA-over-RTMR internally unifies with the log format that > > is shared with RTMR-user-ABI. > > > I'm not a TCG expert. As far as I know, > https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf > > defines the event types for TCG2 logs for firmware uses only. I > cannot find a spec that defines event types for OS or applications. > We may reuse the firmware event types for Linux but I doubt they can > accommodate IMA. The TCG crypto agile log format is index (32 bit), event tag (32 bit), digests array, sized event entry (up to 4GB) So an IMA log entry can definitely be transformed into this format (providing someone agrees to the tag or set of tags). The slight problem would be that none of the current IMA tools would understand it, but that could be solved over time (the kernel could use the TCG format internally but transform to the IMA format for the current securityfs IMA log). > IMHO, we don't have to follow TCG2 format because TDX is never TPM, > nor are any other TEEs that support runtime measurements. The > existing TCG2 format looks to me somewhat like ASN.1 - well defined > but schema is needed to decode. In contrast, JSON is a lot more > popular than ASN.1 nowadays because it's human readable and doesn't > require a schema. I just wonder if we should introduce a text based > log format. We could make the log a text file, in which each line is > an event record and the digest of the line is extended to the > specified runtime measurement register. The content of each line > could be free-form at the ABI level, but we can still recommend a > convention for applications - e.g., the first word/column must be an > URL for readers to find out the format/syntax of the rest of the > line. Thoughts? https://xkcd.com/927/ > > ...but be warned the above is a comment from someone who knows > > nothing about IMA internals, just reacting to the comment. > > > > > > > > I am wondering where will the event log be stored? Is it in the > > > > log_area region of CCEL table? > > > > > > IMA stores its log in kernel memory and makes it visible in > > > securityfs (in the smae place as the measured boot log). Since > > > this interface is using configfs, that's where I'd make the log > > > visible. > > > > > > Just to add a note about how UEFI works: the measured boot log is > > > effectively copied into kernel memory because the UEFI memory it > > > once occupied is freed after exit boot services, so no UEFI > > > interface will suffice for the log location. > > > > > > I'd make the file exporting it root owned but probably readable > > > by only the people who can also extend it (presumably enforced by > > > group?). > > > > I assume EFI copying into kernel memory is ok because that log has > > a limited number of entries. If this RTMR log gets large I assume > > it needs some way cull entries that have been moved to storage. > > Maybe this is a problem IMA has already solved. > > We don't have to, and are also not supposed to I guess, append to the > log generated by BIOS. We do actually: the EFI boot stub in the kernel appends entries for the initrd and command line. > The kernel can start a new log, and potentially in a different > format. I think the BIOS log is exposed via securityfs today. Am I > correct? I already said that, yes. > For the new TEE measurement log, I don't think it has to be > collocated with the BIOS log, because TEEs are never TPMs. This depends. Logs are separable by PCRs. As in every entry for the same PCR could be in a separate, correctly ordered, log. However, you can't have separate logs that both use the same PCR because they won't replay. James
On Mon, Feb 12, 2024 at 11:36:27PM -0800, Xing, Cedric wrote: > On 2/9/2024 12:58 PM, Dan Williams wrote: > > James Bottomley wrote: > > > Just to correct this: IMA uses its own log format, but I think this was > > > a mistake long ago and the new log should use TCG2 format so all the > > > tools know how to parse it. > > > > Is this a chance to nudge IMA towards a standard log format? In other > > words, one of the goals alongside userspace consumers of the RTMR log > > would be for IMA to support it as well as an alternate in-kernel backend > > next to TPM. IMA-over-TPM continues with its current format, > > IMA-over-RTMR internally unifies with the log format that is shared with > > RTMR-user-ABI. > > > I'm not a TCG expert. As far as I know, https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf > defines the event types for TCG2 logs for firmware uses only. I cannot find > a spec that defines event types for OS or applications. We may reuse the > firmware event types for Linux but I doubt they can accommodate IMA. > > IMHO, we don't have to follow TCG2 format because TDX is never TPM, nor are > any other TEEs that support runtime measurements. The existing TCG2 format > looks to me somewhat like ASN.1 - well defined but schema is needed to > decode. In contrast, JSON is a lot more popular than ASN.1 nowadays because > it's human readable and doesn't require a schema. I just wonder if we should > introduce a text based log format. We could make the log a text file, in > which each line is an event record and the digest of the line is extended to > the specified runtime measurement register. The content of each line could > be free-form at the ABI level, but we can still recommend a convention for > applications - e.g., the first word/column must be an URL for readers to > find out the format/syntax of the rest of the line. Thoughts? There's also the 'Canonical Event Log' format from TCG. It covers IMA but it looks it's PC/client specific otherwise. systemd seems to be following this format for its systemd-pcr* services and exposing the log in JSON format under /run/log [1]. [1] https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrphase.service.html > > > ...but be warned the above is a comment from someone who knows nothing > > about IMA internals, just reacting to the comment. > > > > > > > > I am wondering where will the event log be stored? Is it in the > > > > log_area region of CCEL table? > > > > > > IMA stores its log in kernel memory and makes it visible in securityfs > > > (in the smae place as the measured boot log). Since this interface is > > > using configfs, that's where I'd make the log visible. > > > > > > Just to add a note about how UEFI works: the measured boot log is > > > effectively copied into kernel memory because the UEFI memory it once > > > occupied is freed after exit boot services, so no UEFI interface will > > > suffice for the log location. > > > > > > I'd make the file exporting it root owned but probably readable by only > > > the people who can also extend it (presumably enforced by group?). > > > > I assume EFI copying into kernel memory is ok because that log has a > > limited number of entries. If this RTMR log gets large I assume it needs > > some way cull entries that have been moved to storage. Maybe this is a > > problem IMA has already solved. > > We don't have to, and are also not supposed to I guess, append to the log > generated by BIOS. The kernel can start a new log, and potentially in a > different format. I think the BIOS log is exposed via securityfs today. Am I > correct? For the new TEE measurement log, I don't think it has to be > collocated with the BIOS log, because TEEs are never TPMs.
On 2/13/2024 8:05 AM, James Bottomley wrote: > On Mon, 2024-02-12 at 23:36 -0800, Xing, Cedric wrote: >> On 2/9/2024 12:58 PM, Dan Williams wrote: >>> James Bottomley wrote: >>>> Just to correct this: IMA uses its own log format, but I think >>>> this was a mistake long ago and the new log should use TCG2 >>>> format so all the tools know how to parse it. >>> >>> Is this a chance to nudge IMA towards a standard log format? In >>> other words, one of the goals alongside userspace consumers of the >>> RTMR log would be for IMA to support it as well as an alternate in- >>> kernel backend next to TPM. IMA-over-TPM continues with its current >>> format, IMA-over-RTMR internally unifies with the log format that >>> is shared with RTMR-user-ABI. >>> >> I'm not a TCG expert. As far as I know, >> https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf >> >> defines the event types for TCG2 logs for firmware uses only. I >> cannot find a spec that defines event types for OS or applications. >> We may reuse the firmware event types for Linux but I doubt they can >> accommodate IMA. > > The TCG crypto agile log format is > > index (32 bit), > event tag (32 bit), > digests array, > sized event entry (up to 4GB) > > So an IMA log entry can definitely be transformed into this format > (providing someone agrees to the tag or set of tags). The slight > problem would be that none of the current IMA tools would understand > it, but that could be solved over time (the kernel could use the TCG > format internally but transform to the IMA format for the current > securityfs IMA log). > Hi James, As Mikko mentioned in his reply, TCG has defined the "Canonical Event Log Format" (aka. CEL) [1], while systemd-pcr* services use a subset of CEL format in their user space log. I skimmed through the CEL spec today. Comparing to TCG2 log, CEL follows the same design (i.e., each event has a type field that determines the structure of the event data) but separates the encoding from the information model. IMHO, CEL only works for applications defined in its information model (currently UEFI BIOS and IMA) but wouldn't work for any other applications like systemd. The systemd source code has documented the difference [2] between their log format and CEL. One problem of CEL is its "content_type", which contains numeric values assigned by the spec. systemd doesn't have a numeric "content_type" assigned so has to use a string value - "systemd", which can only be encoded in JSON but not in TLV or CBOR. Technically, the systemd log is NOT CEL even though they claim that's a subset of it. Another problem of CEL is that NOT every byte of an event is hashed/extended. CEL spec has defined for each "content_type" the subset of bytes to hash, so a verifier must understand ALL content types to be able to verify the integrity of a log. In other words, the integrity of a "systemd" log can never be verified by a CEL conformant verifier. So I wouldn't recommend CEL to be the log format here. We are looking for, as I believe, is a format that can accommodate all applications and allow application-agnostic verifiers. For every event, the kernel only needs to know what to store in the log, and what to hash/extend and to which measurement registers, but isn't concerned by the semantics of the event. If reusing CEL terms, what needs to be defined here is the "encoding" (so that every application can store/extend "something" in a log that every verifier knows how to replay); while every application should be allowed to define its own "information model". -Cedric [1] https://trustedcomputinggroup.org/resource/canonical-event-log-format/ [2] https://github.com/systemd/systemd/blob/e1390da0256bbe2017c4c2fbc636c54fe02c84cb/src/shared/tpm2-util.c#L6112 >> IMHO, we don't have to follow TCG2 format because TDX is never TPM, >> nor are any other TEEs that support runtime measurements. The >> existing TCG2 format looks to me somewhat like ASN.1 - well defined >> but schema is needed to decode. In contrast, JSON is a lot more >> popular than ASN.1 nowadays because it's human readable and doesn't >> require a schema. I just wonder if we should introduce a text based >> log format. We could make the log a text file, in which each line is >> an event record and the digest of the line is extended to the >> specified runtime measurement register. The content of each line >> could be free-form at the ABI level, but we can still recommend a >> convention for applications - e.g., the first word/column must be an >> URL for readers to find out the format/syntax of the rest of the >> line. Thoughts? > > https://xkcd.com/927/ > That is funny :-D I can't agree more, so "no log" I think is always an option. >> For the new TEE measurement log, I don't think it has to be >> collocated with the BIOS log, because TEEs are never TPMs. > > This depends. Logs are separable by PCRs. As in every entry for the > same PCR could be in a separate, correctly ordered, log. However, you > can't have separate logs that both use the same PCR because they won't > replay. > We can have separate logs for the same PCR as long as there's a way to order those logs. A simple way is to record the current PCR value at the beginning of every log, then a verifier can always replay the log to get the PCR value at exit, and use that value to match the next log. Anyway, those details are unimportant. What I intended to say was that those logs don't have to be in the same format. > James > > >
Xing, Cedric wrote: > On 2/13/2024 8:05 AM, James Bottomley wrote: [..] > > The TCG crypto agile log format is > > > > index (32 bit), > > event tag (32 bit), > > digests array, > > sized event entry (up to 4GB) > > > > So an IMA log entry can definitely be transformed into this format > > (providing someone agrees to the tag or set of tags). The slight > > problem would be that none of the current IMA tools would understand > > it, but that could be solved over time (the kernel could use the TCG > > format internally but transform to the IMA format for the current > > securityfs IMA log). > > > Hi James, > [..] > Another problem of CEL is that NOT every byte of an event is > hashed/extended. CEL spec has defined for each "content_type" the subset > of bytes to hash, so a verifier must understand ALL content types to be > able to verify the integrity of a log. In other words, the integrity of > a "systemd" log can never be verified by a CEL conformant verifier. Wait, James said, "crypto agile log format", not CEL. Crypto agile log format looks more generic, no "recnum" for example. [..] > >> IMHO, we don't have to follow TCG2 format.. [..] > > https://xkcd.com/927/ > > > That is funny :-D > > I can't agree more, so "no log" I think is always an option. So to me, "no log" means that instead of going from 14 standards going to 15, the kernel is saying "whee, infinite userspace log formats!", an abdication of its role to support a stable application ABI. The job here to define a kernel de-facto standard for the tags that this configs implementation of a cryto agile log emits, right? As James says: "(providing someone agrees to the tag or set of tags)"
On Mon, Feb 12, 2024 at 11:36:27PM -0800, Xing, Cedric wrote: Hi, I hope the week is going well for everyone. > On 2/9/2024 12:58 PM, Dan Williams wrote: > >James Bottomley wrote: > >>Just to correct this: IMA uses its own log format, but I think this was > >>a mistake long ago and the new log should use TCG2 format so all the > >>tools know how to parse it. > > > >Is this a chance to nudge IMA towards a standard log format? In other > >words, one of the goals alongside userspace consumers of the RTMR log > >would be for IMA to support it as well as an alternate in-kernel backend > >next to TPM. IMA-over-TPM continues with its current format, > >IMA-over-RTMR internally unifies with the log format that is shared with > >RTMR-user-ABI. > I'm not a TCG expert. As far as I know, > https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf > defines the event types for TCG2 logs for firmware uses only. I > cannot find a spec that defines event types for OS or > applications. We may reuse the firmware event types for Linux but I > doubt they can accommodate IMA. > > IMHO, we don't have to follow TCG2 format because TDX is never TPM, > nor are any other TEEs that support runtime measurements. The > existing TCG2 format looks to me somewhat like ASN.1 - well defined > but schema is needed to decode. In contrast, JSON is a lot more > popular than ASN.1 nowadays because it's human readable and doesn't > require a schema. I just wonder if we should introduce a text based > log format. We could make the log a text file, in which each line is > an event record and the digest of the line is extended to the > specified runtime measurement register. The content of each line > could be free-form at the ABI level, but we can still recommend a > convention for applications - e.g., the first word/column must be an > URL for readers to find out the format/syntax of the rest of the > line. Thoughts? A common text based security event description format, based on JSON encoding of LSM security event descriptions, surfaced through securityfs, has already been implemented, proposed and has been pushed out for review twice. The TSEM LSM is designed to be a generic security modeling and security event description export architecture. The V2 patches and discusion around those can be found here: https://lore.kernel.org/lkml/20230710102319.19716-1-greg@enjellic.com/T/#t We have a rather significant upgrade to that patchset that we are staging up for a V3 release. The fundamental premise for TSEM is the encoding and modeling of the parameters that describe LSM based security events. It is designed to be a model/policy agnostic scheme for generating attestations on the state of the platform at large or a workload. Workload models are supported by a concept known as a security modeling namespace, much like any other namespace, that tracks events for an isolated process heirarchy. The most important review comment on the V1 patchset, that can also be found on lore, was by Greg Kroah-Hartmann who suggested using a standardized encoding scheme like JSON for the event descriptions. If you look at his comments, he indicated that there is little rationale for not using an encoding format that the entire technology industry trusts and uses. FWIW, we made the change to JSON and have never looked back, it was the most positive review comment we received. The current format would not seem to have any issues supporting IMA style attestation. For example, the most important event for IMA would be a file open event. Here is an example of the encoding generated for that event: { "event": { "process": "quixote", "type": "file_open", "ttd": "219", "p_ttd": "219", "task_id": "20e07b3614ee37869391849278dfe7285f37ec2362f7d10c052e6715ad888584", "p_task_id": "20e07b3614ee37869391849278dfe7285f37ec2362f7d10c052e6715ad888584", "ts": "6535350020298" }, "COE": { "uid": "0", "euid": "0", "suid": "0", "gid": "0", "egid": "0", "sgid": "0", "fsuid": "0", "fsgid": "0", "capeff": "0x3ffffffffff" }, "file_open": { "file": { "flags": "32800", "inode": { "uid": "50", "gid": "50", "mode": "0100755", "s_magic": "0xef53", "s_id": "xvda", "s_uuid": "feadbeaffeadbeaffeadbeaffeadbeaf" }, "path": { "dev": { "major": "202", "minor": "0" }, "pathname": "/opt/Quixote/sbin/runc" }, "digest": "81f73a59be3d122ab484d7dfe9ddc81030f595cc59968f61c113a9a38a2c113a" } } } There is sufficient information included to track the digests of executable files, or any other type of file for that matter, for any user on the system. This isn't an attempt to pitch TSEM, but rather to suggest the utility of a self-describing JSON format for security logging. As GKH correctly noted in his review comments, there is a great deal of utility to be had by using a format that has significant and mature userspace tooling support. Our own work and deployments have also indicated a great deal of utility to having log entries that are self-describing. One additional observation that may be of use with respect to anyone pursueing an alternate event log format has come out of our data science team. They indicate there has been significant work in the Elastic search community with respect to the development of standardized descriptions of events for logging and other purposes, reference the following URL: https://www.elastic.co/guide/en/ecs/current/index.html Our data team is looking at modifying our current security event descriptions to be as consistent as possible with existing standards for identifying event parameters. Given that attestation and host based security event modeling are only going to become more important in the future, there would seem to be utility in working towards contributing to standardized descriptions for security relevant logs. Hopefully the above reflections are of assistance in furthering the various agendas that are involved. Have a good remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project
On 2/14/2024 10:14 PM, Dan Williams wrote: > Xing, Cedric wrote: >> On 2/13/2024 8:05 AM, James Bottomley wrote: > [..] >>> The TCG crypto agile log format is >>> >>> index (32 bit), >>> event tag (32 bit), >>> digests array, >>> sized event entry (up to 4GB) >>> >>> So an IMA log entry can definitely be transformed into this format >>> (providing someone agrees to the tag or set of tags). The slight >>> problem would be that none of the current IMA tools would understand >>> it, but that could be solved over time (the kernel could use the TCG >>> format internally but transform to the IMA format for the current >>> securityfs IMA log). >>> >> Hi James, >> > [..] >> Another problem of CEL is that NOT every byte of an event is >> hashed/extended. CEL spec has defined for each "content_type" the subset >> of bytes to hash, so a verifier must understand ALL content types to be >> able to verify the integrity of a log. In other words, the integrity of >> a "systemd" log can never be verified by a CEL conformant verifier. > > Wait, James said, "crypto agile log format", not CEL. Crypto agile log > format looks more generic, no "recnum" for example. > If I'm not mistaken, "crypto agile log" refers to the same format as "TCG2 log". It's "crypto agile" because it allows a plurality of hash algorithms/digests (specified in the "digests" array) to be extended to one PCR - each algorithm supported is called a "bank" of the PCR. CEL is also "crypto agile". I'm not familiar with its history but it seems emerged after the TCG2 log format, as CEL's information model is a superset of TCG2's. Specifically, CEL's information model covers 3 applications - "CEL management" (owned by TCG/CEL), "PC Client STD" (owned by TCG PC Client WG and equivalent to TCG2 log), and IMA. Supporting any new applications would require expanding CEL's information model - i.e., by changing the CEL spec. > [..] >>>> IMHO, we don't have to follow TCG2 format.. > [..] >>> https://xkcd.com/927/ >>> >> That is funny :-D >> >> I can't agree more, so "no log" I think is always an option. > > So to me, "no log" means that instead of going from 14 standards going > to 15, the kernel is saying "whee, infinite userspace log formats!", an > abdication of its role to support a stable application ABI. > If we look at how CEL is defined, it separates information model from encoding. Information models have to be contextualized within specific applications, but encodings don't. The reason for 14 standards is because there are 14 different applications. The 15th may be able to combine the existing 14 into a single one, but probably cannot accommodate the 16th. So I think the only practical approach is to abandon the information model and focus on the encoding only. For example, JSON is just a set of encoding rules without an information model, hence can serialize data for all applications. Coming back to the TSM log, the real question is: Can we just specify the encoding without an information model? The answer is yes and no. The kernel does need to know something, such as what to log, what to hash, and extend to which MR, but does NOT need to understand anything else about the event. So a potential ABI definition could be: - Take the MR index and an *encoded* log entry as parameters from user mode. - Hash the whole entry as-is using the same algorithm as used in MR extension, and extend the resulted digest to the specified MR. - Append the whole entry as-is to the log file. The key difference between the aforementioned and CEL is that the former takes the *encoded* log entry as a single input to alleviate the kernel from the necessity of comprehending the logger's information model. > The job here to define a kernel de-facto standard for the tags that this > configs implementation of a cryto agile log emits, right? As James says: > > "(providing someone agrees to the tag or set of tags)" I don't think we should define any tags because that can only be done for existing applications but can never address the needs of future applications. We don't have to maintain a log. The existing TPM module doesn't maintain a log either. systemd on the other hand is an example of keeping measurement logs in user mode. But if we agree that a log is indeed necessary, I'd recommend the aforementioned approach. We can then focus discussions on the options for encoding log entries.
Hi James, On Wed, Feb 07, 2024 at 04:46:36PM -0500, James Bottomley wrote: > Just to correct this: IMA uses its own log format, but I think this was > a mistake long ago and the new log should use TCG2 format so all the > tools know how to parse it. At last year's Plumbers BoF on PCI device authentication & encryption, you requested that the kernel exposes proof of SPDM signature validation so that user space can verify after the fact that the kernel did everything correctly. Your above comment seems to indicate that you prefer TCG2 CEL as the format to expose the information, however the format seems ill-suited for the purpose: Per TCG PFP v1.06r52 sec 3.3.7, an SPDM CHALLENGE event merely logs the nonce used. That's not sufficient to verify the signature: The signature is computed over a hash of the concatenation of all the messages exchanged with the device: * GET_VERSION request + VERSION response * GET_CAPABILITIES request + CAPABILITIES response * NEGOTIATE_ALGORITHMS request + ALGORITHMS response * GET_DIGESTS request + DIGESTS response * GET_CERTIFICATE request + CERTIFICATE response (can be multiple) * CHALLENGE request + CHALLENGE_AUTH response The content of those SPDM messages is not necessarily static: E.g. the SPDM requester (the kernel) presents all supported algorithms and the SPDM responder (the device) selects one of them. If only the nonce is saved in the log, the verifier in user space would need to know exactly which algorithms were supported by the SPDM requester at the time the request was sent (could since have changed through a kernel update). It also needs to know exactly which algorithm the SPDM responder picked. Armed with the knowledge which algorithm bits were set, the verifier would have to reconstruct the messages that were exchanged between SPDM requester and responder so that it can calculate the hash over their concatenation and verify the signature. The algorithm selection is but one example of bits that can vary between different requesters/responders and between different points in time. The SPDM protocol allows a great deal of flexibility/agility here. The nonces sent by requester and responder are not the only bits that are variable, is what I'm trying to say. Storing the nonces in the log is sufficient to prove their freshness, but it is not sufficient to prove correct validation of the signature. I'd have to store the full concatenation of all exchanged SPDM messages in the log to facilitate that. Personally I have no problem doing so, but it won't be possible with the CEL format as currently specified by TCG. So on the one hand I'd like to fulfil your Plumbers request to expose proof of correct signature validation and on the other hand you're requesting CEL format which is insufficient to fulfil the request. I don't really know how to reconcile that. I do see value in exposing the full concatenation of all exchanged SPDM messages: It would allow piping that into wireshark or tshark to decode the messages into human-readable form, which might be useful for debugging SPDM communication with the device. In fact, an SPDM dissector for wireshark already exists, though it's not up-to-date (last change 3 years ago) and probably needs a cleanup before it can be upstreamed: https://github.com/jyao1/wireshark-spdm/ I'm considering adding a custom sysfs interface which exposes the last, say, 64 SPDM events of each device, comprising: * type of event (CHALLENGE or GET_MEASUREMENTS) * timestamp * all exchanged messages * hash of all exchanged messages * hash algorithm used * signature received from device * certificate chain used for signature validation The memory consumption for all that data would be significant and the format wouldn't be TCG2 CEL, but it would fulfil your request to provide proof of signature verification. Thoughts? Thanks, Lukas
Hi James, In the past couple of weeks I've been thinking about what should be a good log format that can be conformant to existing standards and accommodate future applications at the same time. After discussing with folks from Alibaba and Intel internally, I created this issue - https://github.com/confidential-containers/guest-components/issues/495 to document what I've found. Although it was written for CoCo, the design I believe is CEL (Canonical Event Log) conformant and generic enough to be adopted by the kernel. Hence, I revive this thread to solicit your opinion. Your valuable time and feedback will be highly appreciated! Thanks! -Cedric On 2/13/2024 8:05 AM, James Bottomley wrote: > On Mon, 2024-02-12 at 23:36 -0800, Xing, Cedric wrote: >> On 2/9/2024 12:58 PM, Dan Williams wrote: >>> James Bottomley wrote: >>>> Just to correct this: IMA uses its own log format, but I think >>>> this was a mistake long ago and the new log should use TCG2 >>>> format so all the tools know how to parse it. >>> >>> Is this a chance to nudge IMA towards a standard log format? In >>> other words, one of the goals alongside userspace consumers of the >>> RTMR log would be for IMA to support it as well as an alternate in- >>> kernel backend next to TPM. IMA-over-TPM continues with its current >>> format, IMA-over-RTMR internally unifies with the log format that >>> is shared with RTMR-user-ABI. >>> >> I'm not a TCG expert. As far as I know, >> https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf >> >> defines the event types for TCG2 logs for firmware uses only. I >> cannot find a spec that defines event types for OS or applications. >> We may reuse the firmware event types for Linux but I doubt they can >> accommodate IMA. > > The TCG crypto agile log format is > > index (32 bit), > event tag (32 bit), > digests array, > sized event entry (up to 4GB) > > So an IMA log entry can definitely be transformed into this format > (providing someone agrees to the tag or set of tags). The slight > problem would be that none of the current IMA tools would understand > it, but that could be solved over time (the kernel could use the TCG > format internally but transform to the IMA format for the current > securityfs IMA log). > >> IMHO, we don't have to follow TCG2 format because TDX is never TPM, >> nor are any other TEEs that support runtime measurements. The >> existing TCG2 format looks to me somewhat like ASN.1 - well defined >> but schema is needed to decode. In contrast, JSON is a lot more >> popular than ASN.1 nowadays because it's human readable and doesn't >> require a schema. I just wonder if we should introduce a text based >> log format. We could make the log a text file, in which each line is >> an event record and the digest of the line is extended to the >> specified runtime measurement register. The content of each line >> could be free-form at the ABI level, but we can still recommend a >> convention for applications - e.g., the first word/column must be an >> URL for readers to find out the format/syntax of the rest of the >> line. Thoughts? > > https://xkcd.com/927/ > >>> ...but be warned the above is a comment from someone who knows >>> nothing about IMA internals, just reacting to the comment. >>> >>> >>>>> I am wondering where will the event log be stored? Is it in the >>>>> log_area region of CCEL table? >>>> >>>> IMA stores its log in kernel memory and makes it visible in >>>> securityfs (in the smae place as the measured boot log). Since >>>> this interface is using configfs, that's where I'd make the log >>>> visible. >>>> >>>> Just to add a note about how UEFI works: the measured boot log is >>>> effectively copied into kernel memory because the UEFI memory it >>>> once occupied is freed after exit boot services, so no UEFI >>>> interface will suffice for the log location. >>>> >>>> I'd make the file exporting it root owned but probably readable >>>> by only the people who can also extend it (presumably enforced by >>>> group?). >>> >>> I assume EFI copying into kernel memory is ok because that log has >>> a limited number of entries. If this RTMR log gets large I assume >>> it needs some way cull entries that have been moved to storage. >>> Maybe this is a problem IMA has already solved. >> >> We don't have to, and are also not supposed to I guess, append to the >> log generated by BIOS. > > We do actually: the EFI boot stub in the kernel appends entries for the > initrd and command line. > >> The kernel can start a new log, and potentially in a different >> format. I think the BIOS log is exposed via securityfs today. Am I >> correct? > > I already said that, yes. > >> For the new TEE measurement log, I don't think it has to be >> collocated with the BIOS log, because TEEs are never TPMs. > > This depends. Logs are separable by PCRs. As in every entry for the > same PCR could be in a separate, correctly ordered, log. However, you > can't have separate logs that both use the same PCR because they won't > replay. > > James > > >
On 3/4/24 7:19 PM, Xing, Cedric wrote: > Hi James, > > In the past couple of weeks I've been thinking about what should be a > good log format that can be conformant to existing standards and > accommodate future applications at the same time. After discussing > with folks from Alibaba and Intel internally, I created this issue - > https://github.com/confidential-containers/guest-components/issues/495 > to document what I've found. Although it was written for CoCo, the > design I believe is CEL (Canonical Event Log) conformant and generic > enough to be adopted by the kernel. Hence, I revive this thread to > solicit your opinion. Your valuable time and feedback will be highly > appreciated! > > Thanks! > > -Cedric > Hi, Closing the loop on testing format options with CNCF CoCo as an adopter community... There was a robust discussion in the issue [1] posted ~1.5 months back on the previous note on this thread. It seems the conversation has tailed off with agreement that the NELR format would work for that containers community. I think that's a good signal for this approach to move forward. [1] https://github.com/confidential-containers/guest-components/issues/495 Regards, Dan