linux-kernel - Re: [PATCH v8 0/4] Allow guest access to EFI confidential computing secret area

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: <9e911444-0772-b3da-3e63-f5d49543c752@linux.ibm.com>
Date:   Fri, 1 Apr 2022 00:05:18 +0300
From:   Dov Murik <dovmurik@...ux.ibm.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     linux-efi@...r.kernel.org, Ashish Kalra <ashish.kalra@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrew Scull <ascull@...gle.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Lenny Szubowicz <lszubowi@...hat.com>,
        Peter Gonda <pgonda@...gle.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Jim Cadden <jcadden@....com>,
        Daniele Buono <dbuono@...ux.vnet.ibm.com>,
        linux-coco@...ts.linux.dev, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, Dov Murik <dovmurik@...ux.ibm.com>
Subject: Re: [PATCH v8 0/4] Allow guest access to EFI confidential computing
 secret area



On 31/03/2022 12:19, Borislav Petkov wrote:
> On Wed, Mar 30, 2022 at 09:11:54AM +0300, Dov Murik wrote:
>> If that's the case, we don't need a secure channel and secret injection.
>> You can use a simple "sev=debug" (or whatever) in the kernel
>> command-line to indicate your needs.
> 
> Yeah, that would work for a normal SEV guest.
> 
> However, if it is an -ES guest, you need to somehow tell it as the guest
> owner: "hey you're being debugged and that's fine."
> 
> Because if you want to singlestep the thing, you're going to land in
> the #VC handler and destroy registers so you want to save them first if
> you're being debugged and then shovel them out to the host somehow. And
> that's another question but first things first.
> 
> And "if you're being debugged" needs to be somehow told the guest
> through a secure channel so that the HV doesn't go and simply enable
> debugging by booting with "sev=debug" and bypass it all.
> 

Note that the HV can also start the VM with SEV completely turned off.
Similarly, it can enable debugging and "fool" the guest.  Of course all
this tricks will affect the measurement, and then the Guest Owner will
know that something is wrong and won't inject the secrets.  If you don't
rely on secret injection anyway, then I think a kernel command-line
param is good enough.  (I might be missing a scenario though)


Maybe you can use KVM_SEV_GET_ATTESTATION_REPORT (ask the host to do it
for you).  But I think it returns only the launch digest, and you can't
figure out the SEV Policy field from it.



> And SNP has access to the policy in the attestation report, says Tom, so
> that's possible there.

True. But not in really early boot? This is all in the sev-guest
platform driver.


> 
> So we need a way to add the debugging aspect to the measurement and be
> able to recreate that measurement quickly so that a simple debugging
> session of a kernel in a guest can work pretty much the same with a SEV*
> guest.
> 
> I'm still digging the details tho...
>