On Mon, Feb 5, 2018 at 5:26 PM, Josh Poimboeuf <[email protected]> wrote: > On Mon, Feb 05, 2018 at 04:37:26PM +0000, Andy Lutomirski wrote: >> On Mon, Feb 5, 2018 at 4:30 PM, Ingo Molnar <[email protected]> wrote: >> > >> > * Andy Lutomirski <[email protected]> wrote: >> > >> >> >> >> >> >> > On Feb 5, 2018, at 3:42 AM, Ingo Molnar <[email protected]> wrote: >> >> > >> >> > >> >> > * Dan Williams <[email protected]> wrote: >> >> > >> >> >> + /* >> >> >> + * Sanitize extra registers of values that a speculation attack >> >> >> + * might want to exploit. In the CONFIG_FRAME_POINTER=y case, >> >> >> + * the expectation is that %ebp will be clobbered before it >> >> >> + * could be used. >> >> >> + */ >> >> >> + .macro CLEAR_EXTRA_REGS_NOSPEC >> >> >> + xorq %r15, %r15 >> >> >> + xorq %r14, %r14 >> >> >> + xorq %r13, %r13 >> >> >> + xorq %r12, %r12 >> >> >> + xorl %ebx, %ebx >> >> >> +#ifndef CONFIG_FRAME_POINTER >> >> >> + xorl %ebp, %ebp >> >> >> +#endif >> >> >> + .endm >> >> > >> >> > Yeah, so this series look pretty good to me, but there's one small >> >> > detail: I think >> >> > RBP should be cleared unconditionally here, even in the >> >> > CONFIG_FRAME_POINTERS=y >> >> > case, because: >> >> >> >> ENCODE_FRAME_POINTER should take care of rbp, though. >> > >> > AFAICS there's various entry paths where it's not used I think: for >> > example the >> > compat system calls in entry_64_compat.S don't seem to encode RBP in such a >> > fashion (unless I missed some macro side effect). >> >> Then that's a separate bug that should be fixed. Josh? > > We don't encode the frame pointer on syscalls, because "fast path" > (though that's obviously no longer a consideration).
Should we start encoding the frame pointer? --Andy
