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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux