Wrong Arithmetic When Computing Guest Code Size

[ppenna]

Context

The ElfInfo::get_va_size() function is used for determining the size of the gest_code slot during the construction of the sand memory layout.

This function calculates the size based on the loadable program headers, which represent the size of the ELF binary when loaded into memory.

Problem

Although the current implementation works, it does not account for guest binaries that have non-loadable segments which still occupy memory at runtime, such as the BSS segment. As a result, the size computation for these binaries will be incorrect.

Solution

To fix this, we should consider arithmetic on sections that are tagged as SHF_ALLOC. From the ELF Specification [1]:

The section occupies memory during process execution. Some control
sections do not reside in the memory image of an object file; this attribute
is off for those sections.

Code References

hyperlight/src/hyperlight_host/src/mem/elf.rs

Lines 62 to 70 in b0ea748

	pub(crate) fn get_va_size(&self) -> usize {
	let max_phdr = self
	.phdrs
	.iter()
	.rev()
	.find(|phdr| phdr.p_type == PT_LOAD)
	.unwrap(); // guaranteed not to panic because of the check in new()
	(max_phdr.p_vaddr + max_phdr.p_memsz - self.get_base_va()) as usize
	}

hyperlight/src/hyperlight_host/src/mem/layout.rs

Lines 321 to 326 in b0ea748

	pub(super) fn new(
	cfg: SandboxConfiguration,
	code_size: usize,
	stack_size: usize,
	heap_size: usize,
	) -> Result<Self> {

External References

1. https://refspecs.linuxfoundation.org/elf/elf.pdf

[syntactically]

Thanks for getting in touch. Do you have a binary that you are able to share with us where you were experiencing a problem? If you have a binary that isn't loading properly, there is probably a bug in our code---but, at least at first glance, I think it may not be what you have conjectured here & this may not be the right way to solve it.

Traditionally, the section/segment split in ELF reflects a split between information needed by a linker and information needed by a loader; most loaders wouldn't pay attention to the section information when thinking about how to lay out the binary in memory at this stage.

Typically, sections like .bss which do not exist in the file on disk are still loaded via a PT_LOAD header which has p_memsz > p_filesz to reflect that the memory image of the segment should be zero-extended over the on-disk representation of the same. Loading a section uncovered by a program header is difficult in the general case, because it would not be clear what permissions should apply to it. You can see in Book III, Section 2 of the SVR4 spec that you shared that the program loading process is expected to work with segments, and .bss is included in the virtual span of a segment header. The current amd64 System V psABI substantiates this in Chapter 5.

For some real world examples, you can see that the musl ld.so implementation also figures out the in-memory size of the binary via the program headers and then also does the mapping based on them, extending with a MAP_ANONYMOUS mapping whenph->p_memsz > ph->p_filesz. The Linux in-kernel ELF loader (which loads static binaries and PT_INTERP interpreters) also calculates the total mapped size via the sum of the PT_LOAD header p_memszs before doing the actual mapping, also based on the phdrs.

[ppenna]

Hello @syntactically,

Thank you for the details. Based on them I was able to identify that this undefined behavior was triggered to other changes that I introduced in my private fork.

Please, close this issue.