linux-kernel - Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

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:   Tue, 29 Sep 2020 07:10:30 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        Andy Lutomirski <luto@...nel.org>
Cc:     "H.J. Lu" <hjl.tools@...il.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        linux-sgx@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Jethro Beekman <jethro@...tanix.com>,
        Cedric Xing <cedric.xing@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asapek@...gle.com, Borislav Petkov <bp@...en8.de>,
        chenalexchen@...gle.com, Conrad Parker <conradparker@...gle.com>,
        cyhanish@...gle.com, "Huang, Haitao" <haitao.huang@...el.com>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Keith Moyer <kmoy@...gle.com>,
        Christian Ludloff <ludloff@...gle.com>,
        Neil Horman <nhorman@...hat.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Patrick Uiterwijk <puiterwijk@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>, yaozhangx@...gle.com,
        Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX
 enclave call

On 9/28/20 4:38 PM, Andrew Cooper wrote:
>>> CET=y, BUG_SPECTRE_V2=y: does not exist
>>> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline
>>> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>>> CET=n, BUG_SPECTRE_V2=n: no retpoline, not vulnerable
>> Just to confirm: does this mean that the CPU mitigates against user
>> code mistraining the branch predictors for CPL0?
> If (and only if) you have eIBRS enabled.
> 
> eIBRS should be available on all CET-capable hardware, and Linux ought
> to use it by default.

You're totally right, of course.  I was (wrongly) thinking about this
VDSO retpoline as kernel code.

There's another wrinkle here.  Let's say we're vulnerable to a
Spectre-v2-style attack and we want to mitigate it on CET hardware that
has enhanced IBRS.  I'm not sure how reliable of a mitigation retpolines
are on enhanced IBRS hardware.  Intel has recommended _against_ using
them in some cases:

> https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf

"On processors that support enhanced IBRS, it should be used for
mitigation instead of retpoline."

I actually authored that bit of the whitepaper, and I recall that this
was not simply a recommendation based on performance advantages of using
enhanced IBRS.  I can dig through some old email if we decide that we
want to explore using a retpoline on enhanced IBRS hardware.

But, let's take a step back.  The changelog for this patch needs to at
least have:

1. What is the attack being mitigated by the retpoline?
2. Do we actually want to mitigate it?
3. What options are there to mitigate it?
4. Which option does this patch use and why?

Right now, there's not even a comment about this.