linux-kernel - Re: [PATCH v3 0/5] configfs-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: <64f2169e5c381_4c1f329451@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date:   Fri, 1 Sep 2023 09:51:42 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
        Dan Williams <dan.j.williams@...el.com>,
        <linux-coco@...ts.linux.dev>
CC:     Brijesh Singh <brijesh.singh@....com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Peter Gonda <pgonda@...gle.com>,
        Borislav Petkov <bp@...en8.de>,
        Dionna Amalie Glaze <dionnaglaze@...gle.com>,
        Samuel Ortiz <sameo@...osinc.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        <linux-kernel@...r.kernel.org>, <tglx@...utronix.de>,
        <lukas@...ner.de>
Subject: Re: [PATCH v3 0/5] configfs-tsm: Attestation Report ABI

[ Add Lukas since 'SPDM' was mentioned ]

Jeremi Piotrowski wrote:
[..]
> > An attestation report is signed evidence of how a Trusted Virtual
> > Machine (TVM) was launched and its current state. A verifying party uses
> > the report to make judgements of the confidentiality and integrity of
> > that execution environment. Upon successful attestation the verifying
> > party may, for example, proceed to deploy secrets to the TVM to carry
> > out a workload. Multiple confidential computing platforms share this
> > similar flow.
> 
> Besides the platform (cpu) attestation report, there are also attestation
> reports from individual secure PCIe devices that we'd want to fetch. This
> uses the SPDM protocol[1]. There is a CHALLENGE command which (too me)
> roughly maps to an attestation request, but also separate interfaces to
> fetch individual measurements and certificates (like the SNP extended
> report interface allows).

Yes, but I am not yet convinced this configfs-tsm interface would get
involved there.

> 
> If this is to become the one attestation interface then we'll need to
> consider that. That will probably require adding a second level
> directory: /sys/kernel/config/tsm/<device path>.

The SPDM situation is different in my mind in that the kernel has an
interest in being able to attest a device itself. Think of cases like
power management where userspace is frozen, but the kernel needs to
validate the device in the resume flow.

For TVMs the kernel would validate devices and the verifying party would
validate the kernel as part of the guest measurement.

The main difficulty again here is evidence format differentiation. My
hope is that there is some standardization or otherwise a way to update
the kernel's verification logic for per-device evidence-formats.  Maybe
eBPF has a role to play in that story, but that's a converstation for a
different patch set.

> 
> [1]: https://www.dmtf.org/sites/default/files/standards/documents/DSP2058_1.0.0_1.pdf