search

riscv-non-isa / riscv-elf-psabi-doc

A RISC-V ELF psABI Document
https://jira.riscv.org/browse/RVG-4
Creative Commons Attribution 4.0 International
663 stars 158 forks source link

Allocate e_flags for landing pad and shadow stack #395

Closed kito-cheng closed 5 months ago

kito-cheng commented 11 months ago

We didn't allocate bit for individual extension generally, but landing pad and (hardware) shadow stack will require dynamic linker to check all dependent DSOs, so it worth to allocate e_flags to those two speical extension.

EF_RISCV_CFI_LP means this binary has build with landing pad, but NOT required the platform has support Zicfilp extension, since Zicfilp is using hint instruction, so it can be safely execute without Zicfilp, dynamic linker will check all dependent DSOs has set this flag, and enable the landing pad checking if all DSOs has support.

EF_RISCV_CFI_SS means this binary requires the Zimop or Zicfiss extension, which is different than EF_RISCV_CFI_LP, because it's NOT using hint instruction, dynamic linker will check all dependent DSOs has set this flag, and enable the shadow stack if all DSOs has support, otherwise enable Zimop mode only.

NOTE: Zicfiss and Zicfilp are not frozen yet, this PR created for asking feedback and implement toolchain PoC

kito-cheng commented 11 months ago

Yes, attribute can encoding that, however the parsing overhead are relative high compare to e_flags, and that will check when start every program with dynamic linker, so I think it might be worth to add it into e_flags to speed up this process, maybe it's time to make attribute section SHF_ALLOC. (https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/386)

Just note, checked with AArch64 / X86, they are using GNU property to mark the binary has using BTI / CET.

jrtc27 commented 11 months ago

Yes, they are using GNU property, which is extensible, not e_flags, which is a tiny consumable resource. So please don't use e_flags.

jrtc27 commented 11 months ago

That is, if you don't want it in .riscv.attributes, put it in another note, but don't put it in e_flags.

kito-cheng commented 11 months ago

Yeah, I am thinking we might introduce property*, and we can position the two such that the Attribute is for the static linker, while the property carries information for the dynamic linker.

* I try to prevent called it GNU property as possible since I don't want to make psABI seems like GNU-ish.

MaskRay commented 11 months ago

e_flags bits are a scarce resource and I agree that we should be careful when allocating new bits. I think .note.gnu.property is probably the best choice for landing pad and shadow stack (prior art: GNU_PROPERTY_X86_FEATURE_1_SHSTK for x86).

Link editors that support Arm BTI/PAC and Intel CET already have code decoding .note.gnu.property, and it would be convenient to extend the support for RISC-V. There is very little parsing overhead.

kito-cheng commented 5 months ago

Moving to program property: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417