linux-kernel - Re: [PATCH] x86/bugs: wrap X86_FEATURE_RSB_CTXSW with ifdef CONFIG

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] [day] [month] [year] [list]

Date:   Fri, 7 May 2021 16:26:57 +0000
From:   Jon Kohler <jon@...anix.com>
To:     Dave Hansen <dave.hansen@...el.com>
CC:     Jon Kohler <jon@...anix.com>, David Woodhouse <dwmw@...zon.co.uk>,
        Jiri Kosina <jkosina@...e.cz>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Ravi Shankar <ravi.v.shankar@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Anthony Steinhauser <asteinhauser@...gle.com>,
        Mike Rapoport <rppt@...nel.org>,
        Anand K Mistry <amistry@...gle.com>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/bugs: wrap X86_FEATURE_RSB_CTXSW with ifdef
 CONFIG_RETPOLINE



> On May 7, 2021, at 12:02 PM, Dave Hansen <dave.hansen@...el.com> wrote:
> 
> On 5/7/21 8:53 AM, Jon Kohler wrote:
>> The only place X86_FEATURE_RSB_CTXSW is currently in use is in
>> arch/x86/entry/entry_{32|64}.S, where its use is wrapped with
>> ifdef CONFIG_RETPOLINE. If someone uses a system with
>> X86_FEATURE_IBRS_ENHANCED and compiles without CONFIG_RETPOLINE
>> but still has spectre v2 set to auto, the kernel log will
>> print that eIBRS is enabled and that RSB stuffing is enabled;
>> however, that stuffing would never occur.
>> 
>> To make this behavior more clear, wrap the enablement of
>> X86_FEATURE_RSB_CTXSW and the resulting log message with ifdef
>> CONFIG_RETPOLINE, such that it is compiled out along with the
>> actions it controls.
>> 
>> This way seems more correct at first glance as this was the way
>> the code was originally written in fdf82a7856b; however, when
>> enhanced IBRS was added, there was a goto added under
>> SPECTRE_V2_CMD_AUTO which bypasses going through retpoline_auto,
>> where X86_FEATURE_RETPOLINE is set.
>> 
>> The other option would be to remove the CONFIG_RETPOLINE from
>> the code in entry_{32|64}.S, such that it would always be
>> compiled no matter what, such that these two areas match.
> 
> This kinda dances around the real issue: Does RSB stuffing have
> mitigation value on enhanced IBRS systems?
> 
> If yes, then we should make the RSB stuffing code in entry*.S available
> separately from CONFIG_RETPOLINE.
> 
> If no, is it because eIBRS systems are not vulnerable, or because RSB
> stuffing has no mitigation value?
> 
> Either way, I'm not sure the approach in this patch is the one we want.

Thanks, Dave, for the prompt response and thats a great question. 

The way the existing documentation reads in bugs.c, all Sklake+
processors are affected by this, so I'd lean towards "yes" to
your question; however, would love the authorative view from Intel
guru's on this, as RSB stuffing is a bit expensive, would be lovely
to drop it on eIBRS systems! :)

In running down the idea for this patch, I did look at Intel's 
"Affected Processors: Transient Execution Attacks & Related Security
Issues by CPU" guide, interestingly enough the CVE for spectre RSB
(v5 / 2018-15572) isn't listed, so I had to depend on what was written
in the various previous commits around this topic.

Anyhow, happy to take up a different approach depending on what the
powers that be at Intel say to needing RSB stuffing on eIBRS. In
addition to the chatter here, I'll see if I can poke around more on
my own as well.

Thanks again,
Jon