Narrow bounds of PT_CHERI_PCC segment #802
Conversation
bsdjhb
left a comment
bsdjhb
left a comment
There was a problem hiding this comment.
I may try a follow-on commit after this to use the set the rank for PCC padding sections to have all the bits below the new flag set to force it to the end of the PCC section. If that works I can remove all the current wonky code to manually re-sort the padding section.
Use a new rank flag to group most "regular" sections not covered by PT_CHERI_PCC. This enables a narrower PT_CHERI_PCC segment that excludes other output sections such as .data. For most output files, the main result is that .data is moved to a higher address outside of PCC bounds.
bsdjhb
force-pushed
the
narrow_pcc_bounds
branch
from
943ed29 to
676bcef
Compare
| // Group sections covered by PT_CHERI_PCC before other PROGBITS and NOBITS | ||
| // sections. | ||
| if (in.pccPadding && in.pccPadding->isNeeded() && | ||
| (osec.type == SHT_PROGBITS || osec.type == SHT_NOBITS) && |
There was a problem hiding this comment.
Thinking this through further, I believe we need to handle more than just PROGBITS/NOBITS. Various allocatable sections like DYNSYM normally go early in the binary, and I'm not sure this would enforce an ordering between that and .rodata if the latter needs to be within PCC bounds? Similarly something like INIT_ARRAY is writable (and also relro as it happens) and I think that will end up being sorted before .data.rel.ro, potentially putting it in PCC bounds?
There was a problem hiding this comment.
So initially I didn't check osec.type at all (and used a positive flag for PCC sections) but this resulted in a fairly disruptive change to the layout of binaries with only a default compartment. Notably, things like .text got moved after .data/.bss. The check I came up with here seemed to result in the least disruptive change as it leaves .text and other PCC sections where they are (as well as non-PROGBITS sections before .text) and just moved PROGBITS/NOBITS sections after the end of PT_CHERI_PCC.
There was a problem hiding this comment.
Yeah, but that's because you're trying to group three distinct regions via a single bit, so no matter how you split it it's going to get things wrong? I think you need some kind of tristate, which may be able to exploit some of the existing flags like RODATA, such that you have:
- R (includes special)
- R(PCC)
- RX(PCC)
- RWX(PCC)
- RW(RELRO,PCC)
- RW(RELRO)
- RW
Compare with the current:
- R (includes special)
- RX
- RWX
- RW(RELRO)
- RW
We need to split the PCC portion of R to be between R and RX, and need to split the PCC portion of RW(RELRO) to be between RWX and RW(RELRO), which are the opposite way round.
2 participants
This doesn't work as well as it might due to the current hack for older CheriBSD runtime loaders deriving read-only caps from PCC, but for now it does move .data out of PCC bounds at least.