Messages in this thread | | | Date | Mon, 14 Aug 2023 20:43:29 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH v2 2/5] tsm: Introduce a shared ABI for attestation reports |
| |
On Mon, Aug 14, 2023 at 09:43:37AM -0700, Dan Williams wrote: > Greg Kroah-Hartman wrote: > > On Mon, Aug 14, 2023 at 12:43:21AM -0700, Dan Williams wrote: > > > One of the common operations of a TSM (Trusted Security Module) is to > > > provide a way for a TVM (confidential computing guest execution > > > environment) to take a measurement of its launch state, sign it and > > > submit it to a verifying party. Upon successful attestation that > > > verifies the integrity of the TVM additional secrets may be deployed. > > > The concept is common across TSMs, but the implementations are > > > unfortunately vendor specific. While the industry grapples with a common > > > definition of this attestation format [1], Linux need not make this > > > problem worse by defining a new ABI per TSM that wants to perform a > > > similar operation. The current momentum has been to invent new ioctl-ABI > > > per TSM per function which at best is an abdication of the kernel's > > > responsibility to make common infrastructure concepts share common ABI. > > > > > > The proposal, targeted to conceptually work with TDX, SEV, COVE if not > > > more, is to define a sysfs interface to retrieve the TSM-specific blob. > > > > > > echo $hex_encoded_userdata_plus_nonce > /sys/class/tsm/tsm0/inhex > > > hexdump /sys/class/tsm/tsm0/outblob > > > > Why is one way a hex-encode file, that the kernel has to parse, and the > > other not? Binary sysfs files should be "pass through" if at all > > possible, why not make them both binary and not mess with hex at all? > > That keeps the kernel simpler, and if userspace wants the hex format, > > they can provide it much easier (with less potential parsing errors). > > I can do that. The concern was the contract around what to do with > partial writes since binary attributes allow writing the middle of the > buffer. So either the attribute needs to enforce that @offset is always > zero, or that the unwritten portion of the buffer is zeroed. I will go > with just enforcing offset=zero writes.
Enforcing that sounds sane, thanks.
greg k-h
| |