nsz added a comment.

In D80791#2210207 <https://reviews.llvm.org/D80791#2210207>, @chill wrote:

> In D80791#2210124 <https://reviews.llvm.org/D80791#2210124>, @danielkiss 
> wrote:
>
>>>> it is not useful to have a bti annotated function unless everything else 
>>>> is bti compatible too: it is all or nothing per elf module.
>>>
>>> This is false. Some functions in an elf module could be in a guarded 
>>> region, some in a non-guarded region. Some function may always
>>> be called in a "BTI-safe" way, which may be unknown to the compiler.
>>
>> Right now the elf and all of the `text` sections considered BTI enabled or 
>> not. The dynamic linkers/loaders can't support this
>> use case without additional information to be encoded somewhere (and 
>> specified). To support such we need to consider grouping/align to page
>> boundaries these functions in the linker because BTI could be controlled by 
>> flags in PTE.
>> With the current spec this usecase is not supported in this way. The user 
>> have to link the BTI protected code into another elf.
>> Side note: The `force-bti` linker option can't work with half BTI enabled 
>> objects.
>
> I suppose this is valid for typical Linux-based systems today.
>
> Is it valid in general, across the whole spectre of operating systems or for 
> bare-metal targets?
>
> Guess not.

the linker may or may not need to generate code (PLT is just one example) and 
the current abi is designed such that it is an elf module level decision if 
that code is bti compatible or not.

this is why i said that the current abi does not support mixed bti and non-bti 
code, however the user can do this if lies to the linker that everything is bti 
compatible so the linker generates stub code accordingly.

i don't see how baremetal can get away here: this is elf abi.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80791/new/

https://reviews.llvm.org/D80791

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to