Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 31 Mar 2022 11:19:28 +0200
From:   Borislav Petkov <bp@suse.de>
To:     Dov Murik <dovmurik@linux.ibm.com>
Cc:     linux-efi@vger.kernel.org, Ashish Kalra <ashish.kalra@amd.com>,
        Brijesh Singh <brijesh.singh@amd.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Andi Kleen <ak@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andrew Scull <ascull@google.com>,
        Dave Hansen <dave.hansen@intel.com>,
        "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        Lenny Szubowicz <lszubowi@redhat.com>,
        Peter Gonda <pgonda@google.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        James Bottomley <jejb@linux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
        Jim Cadden <jcadden@ibm.com>,
        Daniele Buono <dbuono@linux.vnet.ibm.com>,
        linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/4] Allow guest access to EFI confidential computing
 secret area
Message-ID: <YkVyIE8H4Ivb6J2l@zn.tnic>
References: <20220228114254.1099945-1-dovmurik@linux.ibm.com>
 <YjydSNnG6EJ1KWx0@zn.tnic>
 <f2fb7553-0313-6393-c93c-2bb6619086dc@linux.ibm.com>
 <YkNQNzNa02Sndu+q@zn.tnic>
 <7696ba46-91c7-7119-bd68-b3521459cf37@linux.ibm.com>
 <247080bd-fef5-c892-7753-f9b7cf650166@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <247080bd-fef5-c892-7753-f9b7cf650166@linux.ibm.com>
Precedence: bulk

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.

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

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

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg