lkml.org 
[lkml]   [2020]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.hansen@intel.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? 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.

\
 
 \ /
  Last update: 2020-09-29 01:21    [W:0.117 / U:23.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site