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

- From: Yu, Yu-cheng \<hidden\>
- Date: 2021-03-16 17:45:46 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2021/03/6303615
- Thread: https://ratatoskr.run/linux-doc/2021/03/6303399/t.md

```text
On 3/16/2021 10:28 AM, Dave Hansen wrote:
> On 3/16/21 10:12 AM, Yu, Yu-cheng wrote:
>> On 3/16/2021 8:49 AM, Dave Hansen wrote:
> ...
>>> 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.
>
> First of all, I think putting the macro in calling.h is wrong if it will
> be used exclusively in the VDSO.  If it's VDSO-only, please put it in a
> local header in the vdso/ directory, maybe even a new cet.h.
>
> Also, Boris asked for two *different* macros for 32 and 64-bit:
>
> https://lore.kernel.org/linux-api/20210310231731.GK23521@zn.tnic/
>
> Could you do that in the next version, please?
>

Yes, we can do two macros, probably in arch/x86/include/asm/vdso.h.
```