[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <761f457d-bbb0-4b8f-e472-6705bc1d3cd1@citrix.com>
Date: Tue, 29 Sep 2020 00:38:11 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>
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 28/09/2020 23:41, Andy Lutomirski wrote:
> On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.hansen@...el.com> wrote:
>> On 9/28/20 3:06 PM, H.J. Lu wrote:
>>>> I'm open to do either solution. My thinking was to initially do things
>>>> vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the
>>>> above solution but I'm also fine doing ALTERNATIVE. Dave kindly briefed
>>>> on details how that thing works and it should be perfectly usable for
>>>> our use case.
>>>>
>>> Since SHSTK and IBT are enabled per process, not the whole machine,
>>> are you going to patch vDSO on a per-process basis?
>> No.
>>
>> Retpolines mitigate Spectre v2 attacks. If you're not vulnerable to
>> Spectre v2, you don't need retpolines.
>>
>> All processors which support CET *also* have hardware mitigations
>> against Spectre v2 and don't need retpolines. Here's all of the
>> possibilities:
>>
>> 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.
> Because this is the
> vDSO, and the situation we're actually concerned about is user code
> mistraining its own branch predictors. This could happen
> cross-process or within the same process.
There is nothing (in Intel parts) which prevents mode same-mode training
of indirect branches, either in user or kernel space.
However, an IBPB on context switch should prevent cross-process trailing
attacks.
~Andrew
Powered by blists - more mailing lists