linux-kernel - Re: [RFC PATCH 14/32] x86/fred: header file with FRED definitions

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: <BBD4EA67-C076-4718-93C6-EB25A59C342B@zytor.com>
Date:   Fri, 23 Dec 2022 11:34:05 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        "Li, Xin3" <xin3.li@...el.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: Re: [RFC PATCH 14/32] x86/fred: header file with FRED definitions

On December 22, 2022 5:03:57 AM PST, Peter Zijlstra <peterz@...radead.org> wrote:
>On Wed, Dec 21, 2022 at 02:58:06AM +0000, Li, Xin3 wrote:
>
>> > > +/* Flags above the CS selector (regs->csl) */
>> > > +#define FRED_CSL_ENABLE_NMI		_BITUL(28)
>> > > +#define FRED_CSL_ALLOW_SINGLE_STEP	_BITUL(25)
>> > > +#define FRED_CSL_INTERRUPT_SHADOW	_BITUL(24)
>> > 
>> > What's the state of IBT WAIT-FOR-ENDBR vs this? That really should also get a
>> > high CS bit.
>> 
>> FRED does provide more possibilities :)
>
>That's not an answer. IBT has a clear defect and FRED *should* fix it.

You are not wrong, of course. That being said, we have not wanted to hitch too many things to the FRED baseline, lest it ends up delayed for implementation/validation reasons. The important thing is that FRED *does* provide the mechanism for addressing that even if it does not make the first implementation.