linux-kernel - Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB

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: <20210407194550.GO25319@zn.tnic>
Date:   Wed, 7 Apr 2021 21:45:50 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Brijesh Singh <brijesh.singh@....com>,
        linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
        ak@...ux.intel.com, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        "H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate
 the memory used for the GHCB

On Wed, Apr 07, 2021 at 01:25:55PM +0200, Borislav Petkov wrote:
> On Tue, Apr 06, 2021 at 02:42:43PM -0500, Tom Lendacky wrote:
> > The GHCB spec only defines the "0" reason code set. We could provide Linux
> > it's own reason code set with some more specific reason codes for
> > failures, if that is needed.
> 
> Why Linux only?
> 
> Don't we want to have a generalized set of error codes which say what
> has happened so that people can debug?

To quote Tom from IRC - and that is perfectly fine too, AFAIC:

<tlendacky> i'm ok with it, but i don't think it should be something dictated by the spec.  the problem is if you want to provide a new error code then the spec has to be updated constantly
<tlendacky> that's why i said, pick a "reason code set" value and say those are what Linux will use. We could probably document them in Documentation/
<tlendacky> the error code thing was an issue when introduced as part of the first spec.  that's why only a small number of reason codes are specified

Yap, makes sense. What we should do in the spec, though, is say: "This
range is for vendor-specific error codes".

Also, is GHCBData[23:16] big enough and can we extend it simply? Or do
we need the spec to at least dictate some ranges so that it can use some bits
above, say, bit 32 or whatever the upper range of the extension is...

Hmmm.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette