Add a new PT_CHERI_PCC segment to define the bounds of code capabilities #792

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.

If the address of base+offset resolves to a target symbol, print that symbol with an offset of 0 as the symbol for a capreloc in the compact output. If the base+offset does not resolve to a target symbol, fall back to using any symbol associated with the base address.

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 pointers that resolve to addresses in these ranges to the bounds of the program header.

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

llvm/tools/llvm-readobj/ELFDumper.cpp

        BaseSymbol = it->second;
        // errs() << "BaseSymbol = SymbolNames[" << Base << "] = " << it->second << "\n";
      }
+      if (Offset != 0 && !opts::ExpandRelocs) {


This becomes more useful once code capabilities use PT_CHERI_PCC bounds as the symbol name remains the name of the function instead of becoming the name of the first symbol in the PT_CHERI_PCC segment with an offset.

bsdjhb · 2025-10-06T19:07:08Z

llvm/tools/llvm-readobj/ELFDumper.cpp

      OS << format(" Base: 0x%lx (", static_cast<unsigned long>(Base))
         << BaseSymbol;
-      if (SymbolOffset >= 0)
+      if (SymbolOffset > 0)


It is debatable perhaps if this is a useful change. I think it is a bit more readable (and wanted to avoid implying a cap reloc offset of 0 since in many cases an offset != 0 can now result in a +0 output after the previous change). I should perhaps include more of the rationale in the commit log.

bsdjhb · 2025-10-06T19:10:13Z

lld/ELF/Writer.cpp

  }

+  // Determine the sections PCC should cover for each compartment.
+  if (config->isCheriAbi) {


Maybe this should be disabled for CHERI MIPS? Currently I only disable the caprelocs changes, but perhaps PT_CHERI_PCC should also be disabled for CHERI MIPS? The experimental cap-table stuff isn't really compatible with it.

Hm, the per-file/function stuff is still ultimately one section accessed relatively to the magic PC-on-function-entry register, right? It's just the PLT ABI (and function descriptor, but that was never implemented outside of my initial out-of-tree undergrad prototype) that is weird with PCC bounds, because $cgp is known to point to the captable on entry, and presumably it indirects everything through that, even things that sensible architectures do PC-relatively, given the lack of PC-relative addressing. So I think you just want isCheriBoundsSection to bail after checking SHF_EXECINSTR for the MIPS PLT ABI? Something like:

if (config->emachine == EM_MIPS && in.mipsAbiFlags) { std::optional<unsigned> abi; invokeELFT(getMipsCheriAbiVariant, abi, *in.mipsAbiFlags); if (abi == DF_MIPS_CHERI_ABI_PLT || abi == DF_MIPS_CHERI_ABI_FNDESC) return false; }

bsdjhb · 2025-10-06T19:11:22Z

lld/ELF/Arch/Cheri.cpp

-// OutputSection.  Returns true if the alignment of any OutputSections were
-// modified.
-static bool alignPCCBounds(PhdrEntry *p) {
+// Determine the required alignment for a single PT_CHERI_PCC segment.  Apply


I could squash this commit down into the previous one if the detailed history here is not useful.

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.

This segment bounds all of the executable and rodata sections as well as any GOTs and PLTs accessed via PCC.

Use an architecture-specific method to compute the required alignment for the PT_CHERI_PCC segment. Align the first section as well as the next section after the last section to this alignment. Round up the memory size of the PT_CHERI_PCC to cover this padding. Note that this does not handle the edge case that the file might need to be padded at the end to ensure that the PT_CHERI_PCC segment does not exceed the bounds of the mapping of the entire file.

- The padding section's flags match the previous section so that it is merged into the same segment. - Treat the padding section as relro if the previous section was relro to avoid forcing a new PT_LOAD due to relro vs non-relro. - Ignore empty text input sections when determining if padding is needed. llvm-mc includes an empty .text section in object files even if there is no .text input

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

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

jrtc27 · 2025-10-17T19:08:55Z

lld/ELF/Target.cpp

 TargetInfo::~TargetInfo() {}

+uint64_t TargetInfo::getCheriRequiredAlignment(uint64_t len) const {
+  error("current target does not provide required Cheri alignment");


Hm, llvm_unreachable like adjustPrologueForCrossSplitStack?

jrtc27 · 2025-10-17T19:14:26Z

lld/ELF/Writer.cpp

+    return true;
+
+  // .got.plt is accessed relative to PCC.
+  if (sec == in.gotPlt->getParent())


igotPlt for completeness? Redundant in reality as it's always in the same OutputSection as gotPlt (except 32-bit Arm which puts it with GotSection) but avoids needing to think about it.

jrtc27 · 2025-10-17T19:14:47Z

lld/ELF/Writer.cpp

+  if (sec == in.gotPlt->getParent())
+    return true;
+
+  // CHERI capability table is accessed relative to PCC.


Comment should say MIPS

jrtc27 · 2025-10-17T19:19:05Z

lld/ELF/Writer.cpp

+    return true;
+
+  // .rodata symbols are accessed relative to PCC.
+  if (sec->name.startswith(".rodata"))


String matching isn't ideal, but we already have to do that elsewhere in Cheri.cpp. I guess in an ideal world we'd figure this out based on the relocations (and maybe even split .rodata into the things that are accessed PC-relatively and the things that are just const variables).

jrtc27 · 2025-10-17T19:35:33Z

lld/ELF/Writer.cpp

  }

+  // Determine the sections PCC should cover for each compartment.
+  if (config->isCheriAbi) {


Hm, the per-file/function stuff is still ultimately one section accessed relatively to the magic PC-on-function-entry register, right? It's just the PLT ABI (and function descriptor, but that was never implemented outside of my initial out-of-tree undergrad prototype) that is weird with PCC bounds, because $cgp is known to point to the captable on entry, and presumably it indirects everything through that, even things that sensible architectures do PC-relatively, given the lack of PC-relative addressing. So I think you just want isCheriBoundsSection to bail after checking SHF_EXECINSTR for the MIPS PLT ABI? Something like:

if (config->emachine == EM_MIPS && in.mipsAbiFlags) { std::optional<unsigned> abi; invokeELFT(getMipsCheriAbiVariant, abi, *in.mipsAbiFlags); if (abi == DF_MIPS_CHERI_ABI_PLT || abi == DF_MIPS_CHERI_ABI_FNDESC) return false; }

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

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

+# RUN: ld.lld --shared %t/plt.o -o %t/plt.so
+# RUN: ld.lld --shared %t/plt_notext.o -o %t/plt_notext.so
+
+# RUN: llvm-readelf -t %t/small_text.so | FileCheck --check-prefix=SMALL_TEXT %s


Use -W so they fit on one line, and kebab-case the prefixes

jrtc27 · 2025-10-17T20:11:18Z

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

+# PLT_NOTEXT-NEXT:         PROGBITS        00000000000053d0 0023d0 000010 00   0   0  1
+# PLT_NOTEXT-NEXT:         [0000000000000003]: WRITE, ALLOC
+
+#--- small_text.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?

jrtc27 · 2025-10-17T20:15:35Z

lld/ELF/Arch/Cheri.cpp

    }

+    // For function relocs, use PCC bounds from the PT_CHERI_PCC segment.
+    if (config->emachine != EM_MIPS && (isFunc || isGnuIFunc)) {


Why does this one get turned off for MIPS?

Also could fold into above if?

jrtc27 · 2025-10-17T20:18:56Z

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

 # RELOC32:      CHERI __cap_relocs [
-# RELOC32-NEXT:   0x013088 Base: 0x11030 (<unknown symbol>) Length: 64 Perms: Code
-# RELOC32-NEXT:   0x013090 Base: 0x11030 (<unknown symbol>) Length: 64 Perms: Code
+# RELOC32-NEXT:   0x013088 Base: 0x11000 (_start+48) Length: 9216 Perms: Code


Base being after _start is odd?

bsdjhb added 4 commits October 6, 2025 11:21

llvm-readelf: Omit symbol offsets of zero in compact caprelocs output

19a4a6c

lld: Add an architecture-specific method to compute CHERI alignment

c1b0d76

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

bsdjhb commented Oct 6, 2025

View reviewed changes

bsdjhb added 6 commits October 6, 2025 15:14

lld: Implement Target::getCheriRequiredAlignment for CHERI RISC-V

4c136e7

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.

lld: Implement Target::getCheriRequiredAlignment for CHERI MIPS

e5917e5

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

lld: Output a PT_CHERI_PCC segment for CheriABI binaries and DSOs

d3b762e

This segment bounds all of the executable and rodata sections as well as any GOTs and PLTs accessed via PCC.

lld: Use PCC bounds from PT_CHERI_PCC segment for function caprelocs

5e1d5f3

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

Add a new PT_CHERI_PCC segment to define the bounds of code capabilities #792

Are you sure you want to change the base?

Add a new PT_CHERI_PCC segment to define the bounds of code capabilities #792

Conversation

bsdjhb commented Oct 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bsdjhb commented Oct 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants