Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIMD-0189: SBPF stricter ELF headers #189

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
131 changes: 131 additions & 0 deletions proposals/0189-sbpf-stricter-elf-headers.md
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 |
Comment on lines +72 to +73

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.

Copy link
Contributor Author

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.

| 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.
Copy link

@topointon-jump topointon-jump Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@topointon-jump topointon-jump Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or is this SIMD associated with an SBPF version?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is associated with a SBPF version (see title), though the specific one is not decided yet.
And these checks will all happen at load time (deployment or feature set change), not at runtime.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we specify in the SIMD where the checks will be performed, and what happens if they fail?


### Dynamic symbol table
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you choose the dynamic symbol table entry SHT_DYNAMIC and not the symbol table elf entry SHT_SYMTAB?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


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.
Loading