Message-ID: <Y9N6nP+Z67TnEaMa@vermeer>
Date:   Fri, 27 Jan 2023 08:17:48 +0100
From:   Samuel Ortiz <sameo@...osinc.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "Shishkin, Alexander" <alexander.shishkin@...el.com>,
        "Shutemov, Kirill" <kirill.shutemov@...el.com>,
        "Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        "Poimboe, Josh" <jpoimboe@...hat.com>,
        "aarcange@...hat.com" <aarcange@...hat.com>,
        Cfir Cohen <cfir@...gle.com>, Marc Orr <marcorr@...gle.com>,
        "jbachmann@...gle.com" <jbachmann@...gle.com>,
        "pgonda@...gle.com" <pgonda@...gle.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        James Morris <jmorris@...ei.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        "Lange, Jon" <jlange@...rosoft.com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linux-pci@...r.kernel.org
Subject: Re: Linux guest kernel threat model for Confidential Computing

On Thu, Jan 26, 2023 at 04:44:49PM +0100, Lukas Wunner wrote:
> On Thu, Jan 26, 2023 at 10:24:32AM +0100, Samuel Ortiz wrote:
> > On Wed, Jan 25, 2023 at 11:03 PM Lukas Wunner <lukas@...ner.de> wrote:
> > > CMA/SPDM (PCIe r6.0 sec 6.31) is in active development on this branch:
> > >
> > > https://github.com/l1k/linux/commits/doe
> > > 
> > > The device authentication service afforded here is generic.
> > > It is up to users and vendors to decide how to employ it,
> > > be it for "confidential computing" or something else.
> > >
> > > Trusted root certificates to validate device certificates can be
> > > installed into a kernel keyring using the familiar keyctl(1) utility,
> > > but platform-specific roots of trust (such as a HSM) could be
> > > supported as well.
> > 
> > This may have been discussed at LPC, but are there any plans to also
> > support confidential computing flows where the host kernel is not part
> > of the TCB and would not be trusted for validating the device cert chain
> > nor for running the SPDM challenge?
> 
> As long as a device is passed through to a guest, the guest owns
> that device.  

I agree. On a SRIOV setup, the host typically owns the PF and assigns
VFs to the guests. Devices must be enlightened to guarantee that once
one of their VFs/interfaces is passed to a trusted VM, it can no longer
be modified by anything untrusted (e.g. the hypervisor).

> It is the guest's prerogative and duty to perform
> CMA/SPDM authentication on its own behalf.  If the guest uses
> memory encryption via TDX or SEV, key material established through
> a Diffie-Hellman exchange between guest and device is invisible
> to the host.  Consequently using that key material for IDE encryption
> protects device accesses from the guest against snooping by the host.

On confidential computing platforms where a security manager (e.g.
Intel TDX module) manages the confidential guests, the IDE key
management and stream settings would be handled by this manager. In
other words, the SPDM requester would not be a Linux kernel.
FWIW, Intel recently published an interesting description of TEE-IO
enabling with TDX [1].

> SPDM authentication consists of a sequence of exchanges, the first
> being GET_VERSION.  When a responder (=device) receives a GET_VERSION
> request, it resets the connection and all internal state related to
> that connection.  (SPDM 1.2.1 margin no 185: "a Requester can issue
> a GET_VERSION to a Responder to reset a connection at any time";
> see also SPDM 1.1.0 margin no 161 for details.)
> 
> Thus, even though the host may have authenticated the device,
> once it's passed through to a guest and the guest performs
> authentication again, SPDM state on the device is reset.
> 
> I'll amend the patches so that the host refrains from performing
> reauthentication as long as a device is passed through.  The host
> has no business mutating SPDM state on the device once ownership
> has passed to the guest.
> 
> The first few SPDM exchanges are transmitted in the clear,
> so the host can eavesdrop on the negotiated algorithms,
> exchanged certificates and nonces.  However the host cannot
> successfully modify the exchanged data due to the man in the middle
> protection afforded by SPDM:  The challenge/response hash is
> computed over the concatenation of the exchanged messages,
> so modification of the messages by a man in the middle leads
> to authentication failure.

Right, I was not concerned by the challenge messages integrity but by
trusting the host with verifying the response and validating the device
cert chains.

> Obviously the host can DoS guest access to the device by modifying
> exchanged messages, but there are much simpler ways for it to
> do that, say, by clearing Bus Master Enable or Memory Space Enable
> bits in the Command Register.  DoS attacks from the host against
> the guest cannot be part of the threat model at this point.

Yes, the host can DoS the guest at anytime it wants and in multiple
ways. It's definitely out of the confidential computing thread model at
least.

Cheers,
Samuel.

[1] https://cdrdv2-public.intel.com/742542/software-enabling-for-tdx-tee-io-fixed.pdf

Powered by blists - more mailing lists