Userspace runtime loader support for sub-library c18n #2267
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
bsdjhb
commented
Dec 11, 2024
bsdjhb
commented
- rtld: Remove code to track start and end offsets of text and rodata
- rtld: Support multiple PT_GNU_RELRO program headers
- rtld: Support multiple PLTs
- elf: Add definition of PT_CHERI_BOUNDS program header type
- elftoolchain: Add support for PT_CHERI_BOUNDS
- rtld: Support narrower PCC bounds via PT_CHERI_BOUNDS
- rtld: Require PT_CHERI_BOUNDS to be exact
- elf: Add definitions for PT_COMPARTMENT and DT_C18NSTRTAB*
- elftoolchain: Add support for PT_COMPARTMENT and DT_C18NSTRTAB*
- rtld: Add compartments for sub-object compartments described by PT_COMPARTMENT
- rtld_c18n: Fix copy/paste typo in _rtld_safebox_code error messages
- rtld: Use compartment IDs from sub-object compartments for policy enforcement
This was used in CHERI-MIPS to enforce stricter PCC bounds for some ABIs but is no longer used.
Iterate over all the program headers in obj_remap_relro and remove the relro fields from Obj_Entry. Skip the call to obj_enforce_relro() in relocate_object() for the rtld object as well as the main program object. obj_enforce_relro() is called later when it safe to reference globals such as page_size. Reviewed by: kib Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D47884 (cherry picked from commit fda0403eb0839b29b0b271c69c5cb6bfc874a3b5)
Add a new Plt_Entry structure that describes the data associated with a PLT including the ELF relocation table and PLT GOT. Count the number of PLTs and allocate an array of Plt_Entry objects in the Obj_Entry. Instead of storing the Obj_Entry pointer in GOTs, store the Plt_Entry pointer. The special wrinkles for PowerPC are a bit hackish here and would need some tweaks before upstreaming.
If an object file includes one or more PT_CHERI_BOUNDS program headers, derive new code capabilities for each header and derive code pointers from the code capability that contains the address. This does not yet check for overlapping bounds or if the resulting PCC bounds are wider than the phdr due to precision.
Fail with an error message if the resulting PCC bounds do not match the segment's relocated address and length.
…MPARTMENT - Recognize the new c18n string table via DT_C18NSTRTAB* and save bounded pointers in each Obj_Entry. - Define a new Compart_Entry type to hold information about a sub-object compartment including its compartment ID, virtual address bounds, and name. The name for sub-object is "<obj name>:<compartment name>". Currently the default compartment for an object does not have a suffix. Possibly it should. - This requires reworking compartment assignment to be more explicitly timed (always after digest_dynamic) rather than a side effect of object_add_name. Since we now always have DT_SONAME if it is present, save a pointer to DT_SONAME in Obj_Entry and prefer it for the library name for a compartment (instead of using the first name added).
…orcement - Add a helper function to lookup the relevant compartment ID for a given virtual address and shared object. - Save a compartment ID for each PLT (based on the address of the associated PLT GOT) and use this as the "subject" (caller) for policy enforcement when handling PLT GOT relocations. - Use the target address of a function call to determine the "object" (callee). Note: rtld currently does not enforce any policy for access to data via the normal GOT.
|
These are the userspace rtld changes to support the psABI extensions to date for sub-library c18n: specifically multiple PT_GNU_RELRO (already merged upstream), multiple PLTs per object, PT_CHERI_BOUNDS, and PT_COMPARTMENT. |
jrtc27
reviewed
Dec 11, 2024
| addr = (Elf_Addr)(uintptr_t)obj->relocbase + offset; | ||
| for (unsigned long i = 0; i < obj->npcc_caps; i++) { | ||
| const char *pcc_cap = obj->pcc_caps[i]; | ||
| if (addr >= (ptraddr_t)pcc_cap && addr < cheri_gettop(pcc_cap)) |
There was a problem hiding this comment.
This won’t work for one-past-the-end
There was a problem hiding this comment.
I don’t know if it’s enough to fall back on the PCC cap with that top if no better one is found or whether picking up bounds from the next one if it exists could be a security concern. If the latter then we’d have to keep them non-contiguous and make this inclusive.
There was a problem hiding this comment.
Hmmm, my initial thought is that for relocations with an addend, we should use the address of the symbol to find a compartment or PCC cap, but things like R_MORELLO_RELATIVE may not have a symbol.
For code pointers, do we think we will likely have a code pointer that is one-past-the-end? I could see why a data pointer might do that? One question I also have about both APIs I have added here are if the arguments should be an address and length or just an address?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.