This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Add bti note property when compiling asm files with -mbranch-protection=bti
AbandonedPublic

Authored by steplong on Dec 16 2020, 4:37 PM.

Details

Summary

Generate the .note.gnu.property section with GNU_PROPERTY_AARCH64_FEATURE_1_BTI
when compiling assembly files with -mbranch-protection=bti.

See https://reviews.llvm.org/D81930 for generating the section when compiling
C/C++ files with -mbranch-protection=bti.

Diff Detail

Event Timeline

steplong created this revision.Dec 16 2020, 4:37 PM
steplong requested review of this revision.Dec 16 2020, 4:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 16 2020, 4:37 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

So the intention here is to generate the property when BTI branch protection is enabled, to guarantee the generate .o indeed has the property set, without requiring to pass the flag -mmark-bti-property explicitly. This is convenient for users.

Or is there a clear reason why one would enable BIT branch protection and not have the property set? What would be that use case?

The .note.gnu.property is already generated when C/C++ files are compiled with -mbranch-protection=bti.
-mmark-bti-property is only for assembly file where the .note.gnu.property should be added manually otherwise.

Do you have any reproducer where C/C++ behaves unexpectedly?

The .note.gnu.property is already generated when C/C++ files are compiled with -mbranch-protection=bti.
-mmark-bti-property is only for assembly file where the .note.gnu.property should be added manually otherwise.

Do you have any reproducer where C/C++ behaves unexpectedly?

I think Ana misunderstood the reason for this patch. We haven't seen any compilation of C/C++ behaving unexpectedly. -mbranch-protection=bti generates the .nute.gnu.property for C/C++ files from our experiments, but doesn't work for assembly files. Is there a reason why assembly files have a different flag (i.e. -mmark-bti-property) to create the .note.gnu.property with the BTI entry?

Thanks for clarifying - so the property is being set for C/C++ files but not for assembly files. I think it should be set automatically for both when one uses clang driver to compile/assemble.

Is there a reason why assembly files have a different flag (i.e. -mmark-bti-property) to create the .note.gnu.property with the BTI entry?

In assembly the compiler can't guarantee the landing pads are in place, therefore it doesn't add it automatically.
The original concept was this the developers should add the landing pads wherever needed and by adding the note they mark the file is compatible with BTI.
After adding BTI to many assembly code it was clear the note is error prone and cumbersome to handle and I thing it provides zero protection against regression issues , so the -mmark-bti-property is introduced.
The developers still should add the landing pads but optionally they could mark the files in the build system instead of the assembly files.
The worry is if the assembly file would be marked automatically the produces binary probably won't run correctly.

Thanks Daniel for the explanation. Was the support added for GNU assembler as well? Is it the same flag name?

Thanks Daniel for the explanation.

No problem at all.

Was the support added for GNU assembler as well? Is it the same flag name?

Not yet, I requested the same flag from our GNU team when the flag is added to Clang.

Can you confirm when the GNU toolchain will have this flag supported in their assembler? Compatibility between LLVM and GNU toolchains is important.

Stephen - I think we can abandon this review. Users will need to be made aware of this additional assembler flag when building .s files with BTI enabled.

steplong abandoned this revision.Jan 6 2021, 11:22 AM