This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 07/22] Enable building libgcc with CET options.


On 11/08/2017 03:06 PM, Tsimbalist, Igor V wrote:
So the question I have WRT this patch is the default setting.  If I
>> understand it correctly, if the assembler supports the appropriate
>> insns, then we enable building target libraries with CET by default.
> 
> That's right.
> 
>> These libraries continue to work on older systems without CET
>> capabilities because the CET specific instructions are interpreted as
>> NOPs on older hardware, right?
> 
> That's correct. One specific note though. The endbr and rdssp instructions
> will be treated as NOPs. Incssp instruction generated by the compiler or
> used in the library will be guarded not to be executed if CET features are
> not enabled.
OK.

> 
>> What about cases where we're running on CET capable hardware, the main
>> program gets compiled without CET, but links against a libgcc with CET.
>> What happens in that case?
> 
> All object files and libraries must have CET property set to make the whole
> application to be CET capable. In your case the program will not be CET
> capable.
Doesn't this imply that other components (linker, dynamic linker) are
working together to verify that the entire application and DSO are
compiled with CET?  What happens when a CET capable application dl-opens
a DSO which is not CET safe?  Does the dynamic linker disable CET at
that point?

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]