Re: [PATCH v23 6/9] x86/entry: Introduce ENDBR macro

[Yu, Yu-cheng]

On 3/16/2021 8:49 AM, Dave Hansen wrote:
> On 3/16/21 8:13 AM, Yu-cheng Yu wrote:
> > --- a/arch/x86/entry/calling.h
> > +++ b/arch/x86/entry/calling.h
> > @@ -392,3 +392,21 @@ For 32-bit we have the following conventions - kernel is built with
> >   .endm
> >   
> >   #endif /* CONFIG_SMP */
> > +/*
> > + * ENDBR is an instruction for the Indirect Branch Tracking (IBT) component
> > + * of CET.  IBT prevents attacks by ensuring that (most) indirect branches
> > + * function calls may only land at ENDBR instructions.  Branches that don't
> > + * follow the rules will result in control flow (#CF) exceptions.
> > + * ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
> > + * instructions are inserted automatically by the compiler, but branch
> > + * targets written in assembly must have ENDBR added manually.
> > + */
> > +.macro ENDBR
> > +#ifdef CONFIG_X86_CET
> > +#ifdef __i386__
> > +	endbr32
> > +#else
> > +	endbr64
> > +#endif
> > +#endif
> > +.endm
>
> Is "#ifdef __i386__" the right thing to use here?  I guess ENDBR only
> ends up getting used in the VDSO, but there's a lot of
> non-userspace-exposed stuff in calling.h.  It seems a bit weird to have
> the normally userspace-only __i386__ in there.
>
> I don't see any existing direct use of __i386__ in arch/x86/entry/vdso.

Good point.  My thought was, __i386__ comes from the compiler having the 
-m32 command-line option, and it is not dependent on anything else.

Alternatively, there is another compiler-defined macro _CET_ENDBR that 
can be used.  We can put the following in calling.h:

#ifdef __CET__
#include <cet.h>
#else
#define _CET_ENDBR
#endif

and then use _CET_ENDBR in other files.  How is that?

In the future, in case we have kernel-mode IBT, ENDBR macros are also 
needed for other assembly files.

Thanks,
Yu-cheng