On Sat, 23 Jul 2022 at 19:20, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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".
>
Fair enough. I still think it is better for general hygiene to apply
these changes, but if there is no urgency, I'll leave this for now and
revisit+rebase somewhere during the next cycle.
