Add a new PT_CHERI_PCC segment to define the bounds of code capabilities #792
Conversation
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.
| BaseSymbol = it->second; | ||
| // errs() << "BaseSymbol = SymbolNames[" << Base << "] = " << it->second << "\n"; | ||
| } | ||
| if (Offset != 0 && !opts::ExpandRelocs) { |
There was a problem hiding this comment.
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.
| OS << format(" Base: 0x%lx (", static_cast<unsigned long>(Base)) | ||
| << BaseSymbol; | ||
| if (SymbolOffset >= 0) | ||
| if (SymbolOffset > 0) |
There was a problem hiding this comment.
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.
| } | ||
|
|
||
| // Determine the sections PCC should cover for each compartment. | ||
| if (config->isCheriAbi) { |
There was a problem hiding this comment.
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.
| // 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 |
There was a problem hiding this comment.
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
|
The clang format errors are all about excessive whitespace in existing tests that I had to update. |
1 participant
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.