linux-kernel - Re: [PATCH Part1 RFC v2 02/20] x86/sev: Save the negotiated GHCB version

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]

Date:   Wed, 12 May 2021 09:03:41 -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,
        tglx@...utronix.de, jroedel@...e.de, thomas.lendacky@....com,
        pbonzini@...hat.com, mingo@...hat.com, dave.hansen@...el.com,
        rientjes@...gle.com, seanjc@...gle.com, peterz@...radead.org,
        hpa@...or.com, tony.luck@...el.com
Subject: Re: [PATCH Part1 RFC v2 02/20] x86/sev: Save the negotiated GHCB
 version


On 5/11/21 1:41 PM, Borislav Petkov wrote:
> On Tue, May 11, 2021 at 01:29:00PM -0500, Brijesh Singh wrote:
>> I ignored it, because I thought I still need to initialize the value to
>> zero because it does not go into .bss section which gets initialized to
>> zero by kernel on boot.
>>
>> I guess I was wrong, maybe compiler or kernel build ensures that
>> ghcb_version variable to be init'ed to zero because its marked static ?
> Yes.
>
> If in doubt, always look at the generated asm:
>
> make arch/x86/kernel/sev.s
>
> You can see the .zero 2 gas directive there, where the variable is
> defined.
>
>> In patch #4, you will see that I increase the GHCB max protocol version
>> to 2, and then min_t() will choose the lower value. I didn't combine
>> version bump and caching into same patch because I felt I will be asked
>> to break them into two logical patches.
> Hmm, what would be the reasoning to keep the version bump in a separate
> patch?

Version 2 of the spec adds bunch of NAEs, and several of them are
optional except the hyervisor features NAE. IMO, a guest should bump the
GHCB version only after it has implemented all the required NAEs from
the version 2. It may help during the git bisect of the guest kernel --
mainly when the hypervisor supports the higher version.