On Fri, Jul 22, 2022 at 9:06 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> Thadeu reports that the retbleed mitigations have broken EFI runtime
> services in mixed mode, as the RET macro now expands to a relative
> branch that jumps to nowhere when executed from the 1:1 mapping of the
> kernel text that the EFI mixed mode thunk uses on its return back to the
> caller.
>
> So as Thadeu suggested in [1], we should switch to a bare 'ret' opcode
> followed by 'int3' (to limit straight line speculation). However, doing
> so leaves an unmitigated RET in the kernel text that is always present,
> even on non-EFI or non-mixed mode systems (which are quite rare these
> days to begin with)
>
> So let's take Thadeu's fix a bit further [..]
Note that Thadeu's patch already made it into my kernel as commit
51a6fa0732d6 ("efi/x86: use naked RET on mixed mode call wrapper"), so
that "take the fix further" should probably be done incrementally.
I'm going to ignore this for 5.19, because I'm not sure how big of a
problem that "unmitigated ret" is. Honestly, it's probably easy enough
to find byte 0xc3 as part of other instructions and constants in the
kernel data section anyway, so I wouldn't worry too much about "hey,
we have a 'ret' instruction here that people could mis-use".
Linus
