SIMD-0189: SBPF stricter ELF headers #189
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,131 @@ | ||
| --- | ||
| simd: '0189' | ||
| title: SBPF stricter ELF headers | ||
| authors: | ||
| - Alexander Meißner | ||
| category: Standard | ||
| type: Core | ||
| status: Idea | ||
| created: 2024-10-21 | ||
| feature: TBD | ||
| extends: SIMD-0178, SIMD-0179 | ||
| --- | ||
|
|
||
| ## Summary | ||
|
|
||
| Imposes more restrictions on what is expected of ELF headers. | ||
|
|
||
| ## Motivation | ||
|
|
||
| After the removal of relocations in SIMD-0178 the ELF layout could be massively | ||
| be simplified by constraining it to a strict subset of what ELF otherwise | ||
| allows. Doing so not only reduces the complexity of validator implementations | ||
| but also reduces the attack surface. | ||
|
|
||
| ## Alternatives Considered | ||
|
|
||
| Moving away from ELF as a container format altogether. However this would only | ||
| gain a very small file size advantage but otherwise loose all tooling | ||
| compatibility. | ||
|
|
||
| ## New Terminology | ||
|
|
||
| None. | ||
|
|
||
| ## Detailed Design | ||
|
|
||
| ### File header | ||
|
|
||
| The file size must not be less than `size_of::<Elf64Ehdr>()` (64 bytes), | ||
| otherwise `ElfParserError::OutOfBounds` must be thrown. | ||
|
|
||
| - `e_ident.ei_mag` must be `[0x7F, 0x45, 0x4C, 0x46]` | ||
| - `e_ident.ei_class` must be `ELFCLASS64` (`0x02`) | ||
| - `e_ident.ei_data` must be `ELFDATA2LSB` (`0x01`) | ||
| - `e_ident.ei_version` must be `EV_CURRENT` (`0x01`) | ||
| - `e_ident.ei_osabi` must be `ELFOSABI_NONE` (`0x00`) | ||
| - `e_ident.ei_abiversion` must be `0x00` | ||
| - `e_ident.ei_pad` must be `[0x00; 7]` | ||
| - `e_type` must be `ET_DYN` (`0x0003`) | ||
| - `e_machine` must be `EM_SBPF` (`0x0263`) | ||
| - `e_version` must be `EV_CURRENT` (`0x00000001`) | ||
| - `e_entry` is checked later (see dynamic symbol table) | ||
| - `e_phoff` must be `size_of::<Elf64Ehdr>()` (64 bytes) | ||
| - `e_shoff` is not checked | ||
| - `e_flags` see SIMD-0161 | ||
| - `e_ehsize` must be `size_of::<Elf64Ehdr>()` (64 bytes) | ||
| - `e_phnum` must not be less than `0x0005` | ||
| - `e_phoff + e_phnum * size_of::<Elf64Phdr>()` must be less than the file size | ||
| - `e_phentsize` must be `size_of::<Elf64Phdr>()` (56 bytes) | ||
| - `e_shnum` is not checked | ||
| - `e_shentsize` must be `size_of::<Elf64Shdr>()` (64 bytes) | ||
| - `e_shstrndx` must be less than `e_shnum` | ||
|
|
||
| If any check fails `ElfParserError::InvalidFileHeader` must be thrown. | ||
|
|
||
| ### Program headers | ||
|
|
||
| | purpose | p_type | p_flags | p_vaddr | | ||
| | --------- | ------------ | ---------- | ------- | | ||
| | bytecode | PT_LOAD | PF_X | 0 << 32 | | ||
| | ro data | PT_LOAD | PF_R | 1 << 32 | | ||
| | stack | PT_GNU_STACK | PF_R, PF_W | 2 << 32 | | ||
| | heap | PT_LOAD | PF_R, PF_W | 3 << 32 | | ||
| | symbols | PT_NONE | | 1 << 63 | | ||
|
|
||
| For each of these predefined program headers: | ||
|
|
||
| - `p_type` must match the `p_type` of the entry in the table above | ||
| - `p_flags` must match the `p_flags` of the entry in the table above | ||
| - `p_offset` must not be less than `e_phoff + e_phnum * size_of::<Elf64Phdr>()` | ||
| - `p_offset` must be less than `file.len() as u64` | ||
| - `p_offset` must be evenly divisible by 8 bytes, | ||
| - `p_vaddr` must match the `p_vaddr` of the entry in the table above | ||
| - `p_paddr` must match the `p_vaddr` of the entry in the table above | ||
| - `p_filesz` must be: | ||
| - `0` if the section is writable (the `PF_W` flag is set) | ||
| - `p_memsz` otherwise (the `PF_W` flag is clear) | ||
| - `p_filesz` must not be greater than `file.len() as u64 - p_offset` | ||
| - `p_memsz` must fit in 32 bits / be less than `1 << 32` | ||
| - `p_align` is ignored | ||
|
|
||
| If any check fails `ElfParserError::InvalidProgramHeader` must be thrown. | ||
|
There was a problem hiding this comment. Do you mind specifying where in the program lifecycle this will be thrown? (i.e. will these new checks be enforced at deployment time? when loading into the program cache for execution? both?) What is the plan for currently deployed programs? There was a problem hiding this comment. Or is this SIMD associated with an SBPF version? There was a problem hiding this comment. It is associated with a SBPF version (see title), though the specific one is not decided yet. There was a problem hiding this comment. Could we specify in the SIMD where the checks will be performed, and what happens if they fail? |
||
|
|
||
| ### Dynamic symbol table | ||
|
There was a problem hiding this comment. Why did you choose the dynamic symbol table entry |
||
|
|
||
| For each entry in the dynamic symbol table: | ||
|
|
||
| - if `st_info` does not contain `STT_FUNC` it is ignored, otherwise: | ||
| - the first `st_value` must be the start of the first program header, | ||
| otherwise `ElfParserError::OutOfBounds` must be thrown | ||
| - every subsequent `st_value` must be the end of the last | ||
| (`st_value + st_size`), otherwise `ElfParserError::OutOfBounds` must be thrown | ||
| - the `st_size` must be greater zero and evenly divisible by 8 bytes (the | ||
| instruction size), otherwise `ElfParserError::InvalidSize` must be thrown | ||
| - `st_value + st_size` must not be greater than the end of the first program | ||
| header, otherwise `ElfParserError::OutOfBounds` must be thrown | ||
| - the last `st_value + st_size` must end at the end of the first program | ||
| header, otherwise `ElfParserError::OutOfBounds` must be thrown | ||
| - the symbol is registered in the function registry for the subsequent | ||
| bytecode verification pass | ||
|
|
||
| In other words the `STT_FUNC` symbols must form an ordered | ||
| [partition](https://en.wikipedia.org/wiki/Partition_of_a_set) of the virtual | ||
| address space of the first program header. | ||
|
|
||
| The `e_entry` filed of the file header must be a `STT_FUNC` entry in the | ||
| dynamic symbol table, otherwise `ElfParserError::InvalidFileHeader` must be | ||
| thrown. | ||
|
|
||
| ## Impact | ||
|
|
||
| The toolchain linker will use a new linker script to adhere to these | ||
| restrictions defined here and thus the change will be transparent to the dApp | ||
| developers. | ||
|
|
||
| The section headers are ignored so arbitrary metadata can continue to be | ||
| encoded there. | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| None. | ||
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we allow these headers? These regions are configured independently of the ELF. Do we allow these headers just so that we can reduce LLVM modifications? Just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is so that the memory regions are correctly reflected in the ELF header. This makes it easier for tooling to detect issues (such as overlap in section allocation) and could simplify the validator implementation in the future.
Also, with the upcoming CPI syscall restrictions (necessary for direct mapping) we will limit pointers provided by the user to come from the stack and heap. Thus their layout will be further solidified.