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: <CAAH4kHYCofTtdjpxKMLO8CMX6kZjQUG69mbbwerwuW0Pk6up9A@mail.gmail.com>
Date:   Tue, 15 Aug 2023 10:16:07 -0700
From:   Dionna Amalie Glaze <dionnaglaze@...gle.com>
To:     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

>
> 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.

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.

-- 
-Dionna Glaze, PhD (she/her)