Re: [PATCH 5.10] x86/retpoline: Move a NOENDBR annotation to the SRSO dummy return thunk

From: Greg Kroah-Hartman
Date: Tue Jul 09 2024 - 01:15:48 EST


On Mon, Jul 08, 2024 at 07:05:41PM +0200, Borislav Petkov wrote:
> On Mon, Jul 08, 2024 at 09:43:05AM -0700, Jim Mattson wrote:
> > The linux-5.10-y backport of commit b377c66ae350 ("x86/retpoline: Add
> > NOENDBR annotation to the SRSO dummy return thunk") misplaced the new
> > NOENDBR annotation, repeating the annotation on __x86_return_thunk,
> > rather than adding the annotation to the !CONFIG_CPU_SRSO version of
> > srso_alias_untrain_ret, as intended.
> >
> > Move the annotation to the right place.
> >
> > Fixes: 0bdc64e9e716 ("x86/retpoline: Add NOENDBR annotation to the SRSO dummy return thunk")
> > Reported-by: Greg Thelen <gthelen@xxxxxxxxxx>
> > Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
> > ---
> > arch/x86/lib/retpoline.S | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S
> > index ab9b047790dd..d1902213a0d6 100644
> > --- a/arch/x86/lib/retpoline.S
> > +++ b/arch/x86/lib/retpoline.S
> > @@ -105,6 +105,7 @@ __EXPORT_THUNK(srso_alias_untrain_ret)
> > /* dummy definition for alternatives */
> > SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
> > ANNOTATE_UNRET_SAFE
> > + ANNOTATE_NOENDBR
> > ret
> > int3
> > SYM_FUNC_END(srso_alias_untrain_ret)
> > @@ -258,7 +259,6 @@ SYM_CODE_START(__x86_return_thunk)
> > UNWIND_HINT_FUNC
> > ANNOTATE_NOENDBR
> > ANNOTATE_UNRET_SAFE
> > - ANNOTATE_NOENDBR
>
> Whoops, those two here didn't look right, thanks for catching this.
>
> Acked-by: Borislav Petkov (AMD) <bp@xxxxxxxxx>
>
> And looking at 6.1, it is wrong there too. :-\
>
> commit 7ef6a7f9b32fdfc8bec0a10e6d5ac5374d4f02e7
> Author: Borislav Petkov (AMD) <bp@xxxxxxxxx>
> Date: Fri Apr 5 16:46:37 2024 +0200
>
> x86/retpoline: Add NOENDBR annotation to the SRSO dummy return thunk
>
> commit b377c66ae3509ccea596512d6afb4777711c4870 upstream.
>
> Greg (KH - there's another Greg on CC too :-)), do you prefer such stable-only
> fixes like that or should we revert the wrong backports and redo them?

Sending fixups like this, for things that are already committed are
fine. But note, someone needs to at least send them to the right place
(i.e. no one cc:ed stable@xxxxxxxxxxxxxxx...) if they wish to see them
applied to a stable kernel...

thanks,

greg k-h