Add a new PT_CHERI_PCC segment to define the bounds of code capabilities by bsdjhb · Pull Request #792 · CTSRD-CHERI/llvm-project

bsdjhb · 2025-10-06T19:03:17Z

This extracts the PT_CHERI_PCC bits from the c18n branch. It includes changes to rewrite the bounds of code capability relocations to use the bounds of the containing PT_CHERI_PCC instead of the bounds of the function.

This is not enabled for CHERI-MIPS.

llvm/tools/llvm-readobj/ELFDumper.cpp

lld/ELF/Writer.cpp

lld/ELF/Arch/Cheri.cpp

bsdjhb · 2025-10-06T19:58:04Z

The clang format errors are all about excessive whitespace in existing tests that I had to update.

lld/ELF/Target.cpp

lld/ELF/Writer.cpp

lld/test/ELF/cheri/riscv/pcc-padding.s

jrtc27 · 2025-10-17T20:12:46Z

lld/test/ELF/cheri/riscv/pcc-padding.s

+#--- text_rodata.s
+
+	.global foo
+	.type	foo, @function
+foo:
+	ret
+	.size	foo, . - foo
+
+	.rodata
+	.global	bar
+	.type	bar, @object
+bar:
+	.space	8192
+	.size	bar, . - bar
+
+#--- rodata_only.s
+
+	.rodata
+	.global	bar
+	.type	bar, @object
+bar:
+	.space	8196
+	.size	bar, . - bar


Why not have rodata.s and link with small-text for one of the tests?

I've had to rework these anyway after the change to use relocations (instead of always placing rodata under PCC bounds) which might not permit sharing as easily.

But aside from the .global (and 8196 vs 8192, which isn't obviously not a typo?) they're (still) all the same, so I don't see why they can't share a single rodata.o?

Here the 8196 is intended to require padding if it were part of a PT_CHERI_PCC segment.

rodata-(un)representable.s?

Hmm, it might be that I can use 8196 for all the test cases

lld/ELF/Arch/Cheri.cpp

lld/test/ELF/cheri/riscv/plt.s

lld/test/ELF/cheri/riscv/pcc-padding.s

lld/ELF/SyntheticSections.cpp

lld/test/ELF/cheri/riscv/pcc-padding.s

jrtc27 · 2025-11-20T18:17:20Z

I think I want to pull "llvm-readelf: Use base+offset to resolve target symbol names" into dev now, and perhaps make the format less obtuse at the same time, since none of that really needs to wait on polishing the PCC bounds implementation.

lld/ELF/Relocations.cpp

bsdjhb

We should perhaps document .data.cheri.* in the commit log? Do we need CheriBSD changes in locore and csu to move some variables into those sections?

bsdjhb · 2025-12-02T18:23:09Z

lld/ELF/Writer.cpp

  if (sec == in.pccPadding->getParent())
    return true;

+  // Like RELRO, sections with some spectial names are


Do we need this explicitly? Won't they already be marked by the PC-relative relocations?

My thinking was that there may be cases where for whatever reason there aren't PC-relative relocations but you nevertheless want them in PCC bounds (somehow obfuscated from the linker). Maybe that's a waste of time. It just felt a bit odd to have .data.cheri.pcc not end up in PCC bounds if you didn't reference it PC-relatively.

lld/ELF/Arch/Cheri.cpp

jrtc27 · 2025-12-02T18:40:10Z

Do we need CheriBSD changes in locore and csu to move some variables into those sections?

Not really. The variables don't actually need to be covered by PT_CHERI_PCC, because we're running before that point (and for csu it's not accessing anything RW), so the warnings are harmless. Ideally we'd have a way to say "R_PC that doesn't need to be in PCC bounds", and then locore can use that. Which would be some kind of new relocation, presumably, that behaves like a PC-relative one in every other respect.

bsdjhb · 2025-12-03T15:54:09Z

Do we need CheriBSD changes in locore and csu to move some variables into those sections?

Not really. The variables don't actually need to be covered by PT_CHERI_PCC, because we're running before that point (and for csu it's not accessing anything RW), so the warnings are harmless. Ideally we'd have a way to say "R_PC that doesn't need to be in PCC bounds", and then locore can use that. Which would be some kind of new relocation, presumably, that behaves like a PC-relative one in every other respect.

So I guess I don't understand what this is doing right now? Today the variables locore, etc. need are still in .data and .bss, so we issue the warning but keep going with your change? Do we need .data.cheri.pcc and .bss.cheri.pcc at all? Right now I think the support for them is incomplete as they will get merged into .data/.bss and not exist as separate output sections, so maybe we should wait to add them until we have a use case for them? Also, I do think for locore type things we may end up using a separate relocation instead to avoid the warning instead of these custom sections?

jrtc27 · 2025-12-03T18:21:50Z

Do we need CheriBSD changes in locore and csu to move some variables into those sections?

Not really. The variables don't actually need to be covered by PT_CHERI_PCC, because we're running before that point (and for csu it's not accessing anything RW), so the warnings are harmless. Ideally we'd have a way to say "R_PC that doesn't need to be in PCC bounds", and then locore can use that. Which would be some kind of new relocation, presumably, that behaves like a PC-relative one in every other respect.

So I guess I don't understand what this is doing right now? Today the variables locore, etc. need are still in .data and .bss, so we issue the warning but keep going with your change? Do we need .data.cheri.pcc and .bss.cheri.pcc at all? Right now I think the support for them is incomplete as they will get merged into .data/.bss and not exist as separate output sections, so maybe we should wait to add them until we have a use case for them? Also, I do think for locore type things we may end up using a separate relocation instead to avoid the warning instead of these custom sections?

Yeah that's true, I had that thought today and just got to verifying it, and yes, .data.cheri.pcc ends up in .data by default, so I'd need to teach it to split it out like .data.rel.ro, and yes, for locore etc we wouldn't be using this, we'd just be using a different relocation. I can just drop it for now until we have an actual use case for it.

Static linkers can emit this ELF program header to describe the ranges of address space that should share PCC bounds. Dynamic linkers should constrain code and function pointers that resolve to addresses in these ranges to the bounds of the segment.

This just uses cheri-compressed-cap.h directly. Probably the existing helper methods in llvm/lib/Target/RISCV/MCTargetDesc should be moved out to llvm/Support so they can be reused here.

Similar to CHERI-RISC-V, this uses cheri-compressed-cap.h directly for CHERI-128.

bsdjhb

Looks good to me.

…DSOs This segment bounds all of the executable sections as well as any GOTs and other sections such as read-only data directly accessed via PCC. The PT_CHERI_PCC segment is aligned and padded to ensure that the segment bounds are exactly representable. The first section in the segment is aligned based on the segment size, and a new .pad.cheri.pcc section is inserted at the end of the segment to provide any needed padding. To simplify capreloc processing, function caprelocs use the bounds of the containing PT_CHERI_PCC segment. Future relative capability relocations should also use these bounds for function and code capabilities. This segment is not output for CHERI-MIPS when using the PLT or function descriptor ABIs as those use a separate mechanism for setting bounds on PCC. Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com>

bsdjhb requested a review from jrtc27 October 6, 2025 19:03

bsdjhb commented Oct 6, 2025

View reviewed changes

llvm/tools/llvm-readobj/ELFDumper.cpp Outdated Show resolved Hide resolved

llvm/tools/llvm-readobj/ELFDumper.cpp Outdated Show resolved Hide resolved

lld/ELF/Writer.cpp Outdated Show resolved Hide resolved

lld/ELF/Arch/Cheri.cpp Show resolved Hide resolved

bsdjhb force-pushed the pt_cheri_pcc branch from f23554a to 5e1d5f3 Compare October 6, 2025 19:53

jrtc27 reviewed Oct 17, 2025

View reviewed changes

bsdjhb force-pushed the pt_cheri_pcc branch 3 times, most recently from 9c2c2ed to 59882ae Compare November 19, 2025 20:04

jrtc27 reviewed Nov 20, 2025

View reviewed changes

lld/test/ELF/cheri/riscv/pcc-padding.s Show resolved Hide resolved

jrtc27 reviewed Nov 20, 2025

View reviewed changes

lld/ELF/SyntheticSections.cpp Outdated Show resolved Hide resolved

jrtc27 reviewed Nov 20, 2025

View reviewed changes

lld/test/ELF/cheri/riscv/pcc-padding.s Outdated Show resolved Hide resolved

bsdjhb force-pushed the pt_cheri_pcc branch from 59882ae to 4f7ddaf Compare November 22, 2025 01:49

jrtc27 force-pushed the pt_cheri_pcc branch 2 times, most recently from c66bf0f to bc6ed71 Compare November 24, 2025 23:55

bsdjhb commented Dec 2, 2025

View reviewed changes

lld/ELF/Relocations.cpp Show resolved Hide resolved

bsdjhb commented Dec 2, 2025

View reviewed changes

jrtc27 force-pushed the pt_cheri_pcc branch from 0560517 to 8f7b289 Compare December 4, 2025 14:37

bsdjhb added 4 commits December 4, 2025 15:54

[ELF] Add an architecture-specific method to compute CHERI alignment

847226b

[ELF][RISCV] Implement Target::getCheriRequiredAlignment

eb3f88d

This just uses cheri-compressed-cap.h directly. Probably the existing helper methods in llvm/lib/Target/RISCV/MCTargetDesc should be moved out to llvm/Support so they can be reused here.

[ELF][MIPS] Implement Target::getCheriRequiredAlignment

fe7bd40

Similar to CHERI-RISC-V, this uses cheri-compressed-cap.h directly for CHERI-128.

jrtc27 force-pushed the pt_cheri_pcc branch from 8f7b289 to c5fb38e Compare December 4, 2025 15:58

bsdjhb commented Dec 4, 2025

View reviewed changes

jrtc27 force-pushed the pt_cheri_pcc branch 2 times, most recently from c45e81b to 372e424 Compare December 4, 2025 23:29

jrtc27 force-pushed the pt_cheri_pcc branch from 372e424 to f59da4a Compare December 4, 2025 23:36

jrtc27 merged commit 7ac34fc into CTSRD-CHERI:dev Dec 5, 2025
6 checks passed

bsdjhb deleted the pt_cheri_pcc branch December 10, 2025 15:04

Conversation

bsdjhb commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bsdjhb commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jrtc27 Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

bsdjhb Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

jrtc27 Nov 20, 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!

bsdjhb Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

jrtc27 Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

bsdjhb Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jrtc27 commented Nov 20, 2025

Uh oh!

Uh oh!

bsdjhb left a comment

Choose a reason for hiding this comment

Uh oh!

bsdjhb Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

jrtc27 Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jrtc27 commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bsdjhb commented Dec 3, 2025

Uh oh!

jrtc27 commented Dec 3, 2025

Uh oh!

bsdjhb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments

jrtc27 Nov 20, 2025 •

edited

Loading

jrtc27 commented Dec 2, 2025 •

edited

Loading