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
