On Mon, 2018-01-08 at 03:59 -0800, H.J. Lu wrote: > On Mon, Jan 8, 2018 at 1:56 AM, Martin Liška <mli...@suse.cz> wrote: > > > > On 01/07/2018 11:59 PM, H.J. Lu wrote: > > > > > > Function return thunk is the same as memory thunk for -mindirect-branch= > > > where the return address is at the top of the stack: > > > > > > __x86_return_thunk: > > > call L2 > > > L1: > > > lfence > > > jmp L1 > > > L2: > > > lea 8(%rsp), %rsp|lea 4(%esp), %esp > > > ret > > > > > > and function return becomes > > > > > > jmp __x86_return_thunk > > Hello. > > > > Can you please explain more usage of the option? Is to prevent a speculative > > execution of 'ret' instruction (which is an indirect call), as described in > > [1]? > > The paper mentions that return stack predictors are commonly implemented in > > some form. > > Looks that current version of Linux patches does not use the option. > > > This option is requested by Linux kernel people. It may be used in > the future.
Right. Essentially the new set of vulnerability are all about speculative execution. Instructions which *don't* get committed, and it's supposed to be like they never happen, actually *do* have side- effects and can leak information. This is *particularly* problematic for Intel CPUs where the CPU architects said "ah, screw it, let's not do memory permission checks in advance; as long as we make sure it's done before we *commit* an instruction it'll be fine". With the result that you can now basically read *all* of kernel memory, and hence all of physical memory, directly from userspace on Intel CPUs. Oops :) The fix for *that* one is to actually remove the kernel pages from the page tables while running userspace, instead of just setting the permissions to prevent access. Hence the whole Kernel Page Table Isolation thing. The next interesting attack is the so-called "variant 2" where the attacker pollutes the branch predictors so that in *kernel* mode the CPU *speculatively* runs... well, whatever the attacker wants. This is one that affects lots of vendors, not just Intel. We mitigate this by eliminating *all* the indirect branches in the kernel, to make it immune to such an attack. This is all very well, but *some* CPUs also pull in predictions from the generic branch target predictor when the return stack buffer has underflowed (e.g. if there was a call stack of more than X depth). Hence, in some cases we may yet end up needing this -mfunction-return= thunk too. As you (Martin) note, we don't use it *yet*. The full set of mitigations for the various attacks are still being put together, and the optimal choice for each CPU family does end up being different.
smime.p7s
Description: S/MIME cryptographic signature
