Add program property and PLT for CFI extension by kito-cheng · Pull Request #417 · riscv-non-isa/riscv-elf-psabi-doc

kito-cheng · 2024-01-04T08:27:16Z

We introduce .note.gnu.property section to store infomations that linker or runtime system may use, and we define two bit for landing pad and shadow stack.

Those two bit will checked by loader - and use that info to enable the landing pad checking and/or shadow stack feature.

kito-cheng · 2024-01-04T08:28:07Z

cc @ved-rivos

riscv-elf.adoc

rui314 · 2024-01-05T07:40:53Z

My concern about this proposal is that, with the 32-bit bitmap, we can't have more than 32 extensions. That might be OK for x86-64 that is controlled only by Intel and AMD, but it is likely that we would have way more extensions than x86-64 for RISC-V. I'm not sure even 64 bits is enough. Maybe we should avoid the bitmap completely?

kito-cheng · 2024-01-05T08:06:15Z

@rui314
GNU property is kind of key-value structure, key is 32 bit integer, and we have 536,870,912 can use for the key per the definition of GNU_PROPERTY_LOPROC and GNU_PROPERTY_HIPROC.

/* Processor-specific semantics, lo */
#define GNU_PROPERTY_LOPROC                     0xc0000000
/* Processor-specific semantics, hi */
#define GNU_PROPERTY_HIPROC                     0xdfffffff

So we have 536,870,912 * 32 rather than only 32-bit bitmap :)

rui314 · 2024-01-05T08:58:39Z

@kito-cheng Ah, you are right. Even though I've implemented the feature to the linker, I forgot the actual on-file format. Thank you for pointing that out!

MaskRay · 2024-01-08T00:43:22Z

Thanks for the proposal. On Arm/x86, if all relocatable files contain .note.gnu.property (which contains NT_GNU_PROPERTY_TYPE_0 notes) with the GNU_PROPERTY_X86_FEATURE_1_IBT bit set, the linker will mark the output as compatible with the feature. Assembly files often lack .note.gnu.property, making the CFI features difficult to deploy...

That said, this is most viable proposal. Defining GNU program property looks good for x86/Arm parity.

You may want to mention that n_type is NT_GNU_PROPERTY_TYPE_0.

Add property for CFI extension

"property" is a heavily overloaded term. Consider "program property" or just use .note.gnu.property to be more specific.

sorear · 2024-02-18T18:43:13Z

@kito-cheng Isn't the usefulness of this degraded by the fact that we only allocate 1 32-bit property instead of the ~ 3 * 32768 allocated on x86? When we start to use the next bitmap, an old linker won't be able to propagate it, and so on.

We introduce .note.gnu.property section to store infomations that linker or runtime system may use, and we define 4 program property classes to specifying the merge semantics, it's used for forward compatibility in linker implementations, allowing linker can correctly handle program property types even if they are not recognized. We don't define any program property within this PR, it would be separate PR like #417

kito-cheng · 2024-02-26T09:03:06Z

Split base program property part into #428

We introduce .note.gnu.property section to store infomations that linker or runtime system may use, and we define 4 program property classes to specifying the merge semantics, it's used for forward compatibility in linker implementations, allowing linker can correctly handle program property types even if they are not recognized. We don't define any program property within this PR, it would be separate PR like #417

kito-cheng · 2024-02-26T09:59:23Z

ChangeLog:

Based on Add program property #428
Rename GNU_PROPERTY_RISCV_FEATURE_1_ZICFILP to GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE
Rename GNU_PROPERTY_RISCV_FEATURE_1_ZICFISS to GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS
Explicitly specify the labeling scheme in GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE, label will always set to 1.

riscv-elf.adoc

kito-cheng · 2024-02-26T13:52:18Z

Changes:

Explicitly specify the labeling scheme in GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE, label will always set to 0.
Add simple landing pad PLT.
Add DT_RISCV_SIMPLE_LP_PLT to mark this object use simple landing pad PLT.

kito-cheng · 2025-06-17T05:17:30Z

Update on binutils part: Nelson is approved, but waiting glibc patch send out before merge.

…V_FEATURE_1_CFI_LP_UNLABELED This patch adds two new GNU properties for RISC-V: GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED. We only add readelf and define the properties in this patch. Ref: riscv-non-isa/riscv-elf-psabi-doc#417

This patch adds support for generating unlabeled landing pad PLT entries for the RISC-V architecture. Unlabeled landing pad will place a LPAD instruction at the PLT entry and PLT header, also PLT header will have few changes due to the offset is different from the original one. Ref: riscv-non-isa/riscv-elf-psabi-doc#417

…V_FEATURE_1_CFI_LP_UNLABELED This patch adds two new GNU properties for RISC-V: GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED. We only add readelf and define the properties in this patch. Ref: riscv-non-isa/riscv-elf-psabi-doc#417

This patch adds support for generating unlabeled landing pad PLT entries for the RISC-V architecture. Unlabeled landing pad will place a LPAD instruction at the PLT entry and PLT header, also PLT header will have few changes due to the offset is different from the original one. Ref: riscv-non-isa/riscv-elf-psabi-doc#417

Define two bit for landing pad and shadow stack, and we plan to defined third bit `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_COMPLEX` for complex labeling scheme.

Changes: - Rename `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE` to `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED` - Fix wrong offset in the first PLT stubs for the simple landing pad PLT.

- Use sw guarded call in PLT entry and PLT header. - Also remove `lpad 0` in the entry of PLT header. - Forbid lazy binding at psABI spec level. This change could unify the PLT entry and PLT header with function signature based PLT.

mylai-mtk · 2025-08-12T06:16:39Z

riscv-elf.adoc

-    sub    t1, t1, t3               # shifted .got.plt offset + hdr size + 12
+    sub    t1, t1, t3               # shifted .got.plt offset + hdr size + 12 


Extraneous space.

mylai-mtk · 2025-08-12T07:01:10Z

riscv-elf.adoc

-function pointer from the GOT. On the first call to a function, the
-entry redirects to the first PLT entry which calls `_dl_runtime_resolve`
-and fills in the GOT entry for subsequent calls to the function:
+And occupies two 16 byte entries for the unlabeled landing pad PLT style:


I guess we don't need to distinguish between unlabeled and func-sig landing pad PLT styles anymore.

mylai-mtk · 2025-08-12T07:04:47Z

riscv-elf.adoc

+executable sections are built to be compatible with the landing pad mechanism
+provided by the Zicfilp extension in the unlabeled scheme: Executables and
+shared libraries with this bit set are required to generate PLTs in the
+unlabeled landing pad PLT style, and all of the labels of lpad instructions are


~~unlabeled~~

riscv-elf.adoc

xypron · 2025-08-14T07:25:32Z

riscv-elf.adoc

+each bit indicating a feature that the object file is compatible with. The
+linker should perform a bitwise AND operation when merging different objects.
+
+The value of `GNU_PROPERTY_RISCV_FEATURE_1_AND` is defined in <<rv-prog-prop-type>>.


This link does not make sense to me here. We are here in the section that defines the values in the lines below.

xypron · 2025-08-14T07:28:04Z

riscv-elf.adoc

+|===
+| Bit | Bit Name
+|   0 | GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED
+|   1 | GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS


Why do we need a bit for unlabeled landing pads?
I would have expected a bit for "have landing pads" and a property for the labeling scheme which may be unlabeled or labeled according to a specific algorithm.

For easy migration of distros we will probably need at least:

no landing pads

landing pads are unlabeled, callers do not set x7

landing pads are unlabeled, but callers set x7 according to labeling scheme

both landing pads and callers abide to labeling scheme

…NU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED This patch adds two new GNU properties for RISC-V: GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED. We only add readelf and define the properties in this patch. Ref: riscv-non-isa/riscv-elf-psabi-doc#417 (cherry picked from commit 4ad5217caf706925014e38be2bc561a2fa094ece) Signed-off-by: Han Gao <gaohan@iscas.ac.cn>

- Remove trailing whitespace in PLT entry code comment. - Simplify "unlabeled landing pad PLT style" to "landing pad PLT style" since there is only one type of landing pad PLT style. - Directly specify the pr_type value of GNU_PROPERTY_RISCV_FEATURE_1_AND instead of referencing the table. - Remove "PLT entries" from the indirect branch origins list since PLT calls are use SW guared call.

kito-cheng requested review from MaskRay, Nelson1225, asb, aswaterman, jrtc27 and rui314 January 4, 2024 08:27

ved-rivos reviewed Jan 4, 2024

View reviewed changes

riscv-elf.adoc Outdated Show resolved Hide resolved

ved-rivos reviewed Jan 4, 2024

View reviewed changes

riscv-elf.adoc Outdated Show resolved Hide resolved

ved-rivos reviewed Jan 4, 2024

View reviewed changes

riscv-elf.adoc Show resolved Hide resolved

kito-cheng changed the title ~~Add property for CFI extension~~ Add program property for CFI extension Jan 11, 2024

kito-cheng mentioned this pull request Feb 2, 2024

Allocate e_flags for landing pad and shadow stack #395

Closed

topperc mentioned this pull request Feb 5, 2024

[RISCV] Add Zicfiss support to the shadow call stack implementation. llvm/llvm-project#68075

Merged

SuHo-llrr mentioned this pull request Feb 15, 2024

[RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension llvm/llvm-project#77414

Closed

kito-cheng mentioned this pull request Feb 26, 2024

Add program property #428

Merged

kito-cheng changed the base branch from master to prog-prop February 26, 2024 09:56

kito-cheng force-pushed the cfi-prop branch from 1e785fa to 6b5ef1b Compare February 26, 2024 09:57

ved-rivos reviewed Feb 26, 2024

View reviewed changes

riscv-elf.adoc Outdated Show resolved Hide resolved

kito-cheng force-pushed the cfi-prop branch from 59ceceb to 6016e63 Compare February 26, 2024 12:43

kito-cheng changed the title ~~Add program property for CFI extension~~ Add program property and PLT for CFI extension Feb 26, 2024

mylai-mtk mentioned this pull request Jun 24, 2025

[LLD][RISCV][Zicfilp] Generate unlabeled landing pad-style PLT llvm/llvm-project#145461

Open

kito-cheng added 14 commits August 11, 2025 18:58

Add program property for CFI extension

0bf517a

Define two bit for landing pad and shadow stack, and we plan to defined third bit `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_COMPLEX` for complex labeling scheme.

Tweak table layout

0ef6c79

Update simple labeling scheme to use 0

2287e78

Add simple landing pad PLT

674fdc1

Drop DT_RISCV_SIMPLE_LP_PLT

26f8548

Add one more nop for alignment

7a17daa

Minor revision

6870e06

Changes: - Rename `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE` to `GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED` - Fix wrong offset in the first PLT stubs for the simple landing pad PLT.

Apply mylai-mtk's comment

b0c58fa

Fix typo

3100056

Minor tweak for grammar

79af4a7

Apply MaskRay's comment for GNU_PROPERTY_RISCV_FEATURE_1_AND

f209417

Add ref rv-prog-prop-type for GNU_PROPERTY_RISCV_FEATURE_1_AND

714f4b9

Add Tool Requirements for Generating Landing Pad Instructions

efe20ea

Update PLT entry

6662782

- Use sw guarded call in PLT entry and PLT header. - Also remove `lpad 0` in the entry of PLT header. - Forbid lazy binding at psABI spec level. This change could unify the PLT entry and PLT header with function signature based PLT.

kito-cheng force-pushed the cfi-prop branch from 21caf60 to 6662782 Compare August 11, 2025 11:03

mylai-mtk reviewed Aug 12, 2025

View reviewed changes

mylai-mtk mentioned this pull request Aug 12, 2025

Introduce new relocation for landing pad #452

Open

xypron reviewed Aug 14, 2025

View reviewed changes

		sub t1, t1, t3 # shifted .got.plt offset + hdr size + 12
		sub t1, t1, t3 # shifted .got.plt offset + hdr size + 12

Conversation

kito-cheng commented Jan 4, 2024

Uh oh!

kito-cheng commented Jan 4, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rui314 commented Jan 5, 2024

Uh oh!

kito-cheng commented Jan 5, 2024

Uh oh!

rui314 commented Jan 5, 2024

Uh oh!

MaskRay commented Jan 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sorear commented Feb 18, 2024

Uh oh!

kito-cheng commented Feb 26, 2024

Uh oh!

kito-cheng commented Feb 26, 2024

Uh oh!

Uh oh!

kito-cheng commented Feb 26, 2024

Uh oh!

kito-cheng commented Jun 17, 2025

Uh oh!

mylai-mtk Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

mylai-mtk Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

mylai-mtk Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

xypron Aug 14, 2025

Choose a reason for hiding this comment

Uh oh!

xypron Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xypron Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

MaskRay commented Jan 8, 2024 •

edited

Loading

xypron Aug 14, 2025 •

edited

Loading

xypron Aug 14, 2025 •

edited

Loading