On 28/09/2020 23:41, Andy Lutomirski wrote: > On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen <dave.han...@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?
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
