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  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]
Date:   Tue, 10 Aug 2021 08:17:00 -0500
From:   Brijesh Singh <>
To:     Borislav Petkov <>
Cc:,,,,,,,,, Thomas Gleixner <>,
        Ingo Molnar <>, Joerg Roedel <>,
        Tom Lendacky <>,
        "H. Peter Anvin" <>, Ard Biesheuvel <>,
        Paolo Bonzini <>,
        Sean Christopherson <>,
        Vitaly Kuznetsov <>,
        Wanpeng Li <>,
        Jim Mattson <>,
        Andy Lutomirski <>,
        Dave Hansen <>,
        Sergio Lopez <>, Peter Gonda <>,
        Peter Zijlstra <>,
        Srinivas Pandruvada <>,
        David Rientjes <>,
        Dov Murik <>,
        Tobin Feldman-Fitzthum <>,
        Michael Roth <>,
        Vlastimil Babka <>,,,
Subject: Re: [PATCH Part1 RFC v4 02/36] x86/sev: Save the negotiated GHCB

On 8/10/21 5:01 AM, Borislav Petkov wrote:
> On Wed, Jul 07, 2021 at 01:14:32PM -0500, Brijesh Singh wrote:
>> The SEV-ES guest calls the sev_es_negotiate_protocol() to negotiate the
>> GHCB protocol version before establishing the GHCB. Cache the negotiated
>> GHCB version so that it can be used later.
>> Signed-off-by: Brijesh Singh <>
>> ---
>>   arch/x86/include/asm/sev.h   |  2 +-
>>   arch/x86/kernel/sev-shared.c | 17 ++++++++++++++---
>>   2 files changed, 15 insertions(+), 4 deletions(-)
> Also, while looking at this, all those defines in sev-common.h were
> bothering me for a while now because they're an unreadable mess because
> I have to go look at the GHCB spec, decode the corresponding MSR
> protocol request and then go and piece together each request value by
> verifying the masks...
> So I did the below which is, IMO, a lot more readable as you can follow
> it directly with the spec opened in parallel.
> Thus, if you don't have a better idea, I'd ask you to please add this to
> your set and continue defining the new MSR protocol requests this way so
> that it can be readable.

thanks Boris, I will include this in my series and rework the remaining 
patches to align with it.


Powered by blists - more mailing lists