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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aea0e0c8-7f03-b9db-3084-f487a233c50b@amd.com>
Date:   Tue, 2 Nov 2021 13:24:01 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     brijesh.singh@....com, x86@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Michael Roth <michael.roth@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Andi Kleen <ak@...ux.intel.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        tony.luck@...el.com, marcorr@...gle.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com
Subject: Re: [PATCH v6 14/42] x86/sev: Register GHCB memory when SEV-SNP is
 active

Hi Boris,


On 11/2/21 11:53 AM, Borislav Petkov wrote:
> On Fri, Oct 08, 2021 at 01:04:25PM -0500, Brijesh Singh wrote:
>> +	/* SEV-SNP guest requires that GHCB must be registered. */
>> +	if (cc_platform_has(CC_ATTR_SEV_SNP))
>> +		snp_register_ghcb(data, __pa(ghcb));
> 
> This looks like more of that "let's register a GHCB at the time the
> first #VC fires".
> 

There are two #VC handlers:

1) early exception handler [do_vc_no_ghcb()]. The handler uses the MSR 
protocol based VMGEXIT.

https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/sev-shared.c#L147


2) exception handler setup during the idt bringup 
[handle_vc_boot_ghcb()]. The handler uses the full GHCB.
https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/sev.c#L1472

To answer your question, GHCB is registered at the time of first #VC 
handling by the second exception handler. Mike can correct me, the CPUID 
page check is going to happen on first #VC handling inside the early 
exception handler (i.e case 1). The early exception handler uses the MSR 
protocol, so, there is no need to register the GHCB page. Before 
registering the page we need to map it unencrypted.


> And there already is setup_ghcb() which is called in the #VC handler.
> And that thing registers a GHCB GPA.
> 

There are two cases that need to be covered 1) BSP GHCB page and 2) APs 
GHCB page. The setup_ghcb() is called for the BSP. Later on, per-cpu 
GHCB page is used by the APs. APs need to register their GHCB page 
before using it.

> But then you have to do it here again.
> 
> I think this should be changed together with the CPUID page detection
> stuff we talked about earlier, where, after you've established that this
> is an SNP guest, you call setup_ghcb() *once* and after that you have
> everything set up, including the GHCB GPA. And then the #VC exceptions
> can come.

See if my above explanation make sense. Based on it, I don't think it 
makes sense to register the GHCB during the CPUID page detection. The 
CPUID page detection will occur in early VC handling.

> Right?
> 
> Or is there a chicken-and-an-egg issue here which I'm not thinking
> about?
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ