On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.hansen@xxxxxxxxx> 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.
