linux-kernel - Re: [PATCH v2 0/5] tsm: Attestation Report ABI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64dbea7e18d6c_47b5729429@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date:   Tue, 15 Aug 2023 14:13:34 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Dionna Amalie Glaze <dionnaglaze@...gle.com>,
        Peter Gonda <pgonda@...gle.com>
CC:     Dan Williams <dan.j.williams@...el.com>,
        Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
        <linux-coco@...ts.linux.dev>,
        "Brijesh Singh" <brijesh.singh@....com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Borislav Petkov" <bp@...en8.de>,
        Samuel Ortiz <sameo@...osinc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        <x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] tsm: Attestation Report ABI

Dionna Amalie Glaze wrote:
> >
> > Why do we need to be so prescriptive about "boot time" vs "runtime"
> > attestations? A user may wish to attest to several requests as Jeremi
> > notes. And why should users be forced into using a vTPM interface if
> > their usecase doesn't require all the features and complexity of a
> > vTPM? Some users may prefer less overall code within their Trusted
> > Computer Base (TCB) and a TPM emulate is a significant code base.
> >
> 
> I agree, and I was a bit too hasty to acquiesce to sysfs due to the
> TPM argument that really only applies for SEV-SNP without a whole lot
> of extra work for other backends (not to say SVSM isn't itself a whole
> lot of extra work).
> 
> > It seems like you are just reading the SNP spec, if you read the TDX
> > spec you'll see there are RTMRs which can be extended with new data.
> > This leads to a different data in the attestation. Similar there are
> > REMs in the ARM CCA spec.
> >
> 
> I'll add a note here that measurement registers are extensible at any
> point by ring0, and there should be an API for doing so, the way that
> there is for /dev/tpmX.
> 
> It could be /dev/teemr or something to unify TDX, COVE, ARM CCA, and
> potentially a measurement register protocol extension to SEV-SNP's
> SVSM.
> I'm not sure how Intel is going to propose abstracting TCG Canonical
> Event Log measurements to reuse measurement-to-PCR<X> code points in
> the kernel as measurement-to-MR<f(X)>, or whatnot, but each technology
> should have that implementation option to extend their own measurement
> registers (and event log, potentially).
> 
> I (and probably James) object with just saying the PCRs are going to
> xyz-measurement-register for simulating that integrity part of a TPM
> to get just the quote aspect and not the rest of TPM 2.0 to hide
> everything behind the TPM abstraction. It doesn't follow the Tcg spec.
> 
> But I repeat myself. If we use any ioctl, we'll end up multiplexing
> the input per-technology, and at that point we essentially have
> manufacturer-specific devices much to Dan's dismay.

I think the ioctl() question is separate from the question of how to
scale an attestation ABI.

While I am not yet convinced that RTMR deserves an ABI separate from
vTPM (or at least a trusted-keys abstraction to reuse the kernel's
existing PCR ABI for TPM-like facilities) the selection of sysfs
precludes the "RTMR and repeated measurements by multiple containers"
use case. One way to buy time for that future conversation while moving
ahead on this base reporting ABI is to switch from sysfs to configfs.
That would allow for per container submission ABI.

It could be approximated with sysfs by having an instance creation
attribute, but it is more natural to just use mkdir to create more
interfaces that can be bind mounted by per-container if need be.

> Sysfs will certainly not be okay for measurement register-only
> technology, since there's no way to not use a hardware attestation to
> securely track measurement changes past "the static boot" (PCRs 0-7).
> I don't want to have to rely on enclave-like peer VMs that perform the
> TPM behavior.

Understood.