Rust BPF: Rustc/LLVM creating invalid relocations

[jackcmay]

Problem

When building Rust modules w/ BPF there are R_BPF_64_RELATIVE relocations that cannot be relocated.

R_BPF_64_RELATIVE relocations refer to 64-bit virtual memory accesses that need to be "fixed-up" when the module is loaded to reflect the actual physical address they were loaded at. The vast majority of the relocations seem reasonable but there are a few that are not. Test cases performed on the Rust module have not executed the code used by these relocations and therefore it may be code that should have been optimized away is not actually part of the flow. More investigation required.

R_BPF_64_RELATIVE relocation entries contain a virtual address of the instruction that needs to be fixed up. During run-time the relocated instruction will attempt to read/write memory from/to 64-bit address. The existing instructions imm field contains the virtual address of the memory it will be accessing. To process a R_BPF_64_RELATIVE relocation the loader locates the instruction being fixed-up, reads the virtual memory address from the instruction's imm field, converts that virtual address into a physical address, and writes the physical address back into the instruction's imm field. Checks are made during this process to ensure that the virtual address in the imm field points to a valid and loadable section in the ELF. In the case of the invalid relocations, the imm field in the instruction is zero but the ELF contains no valid virtual address of zero. The best we could do is interpret it as a raw file offset but that would point the ELF header. Maybe that is what is intended but unlikely and highly irregular. More investigation needs to be done to determine where these invalid relocations are being generated, what original rust source code they are tied to, and why the imm fields are zero.

Proposed Solution

[jackcmay]

As noted earlier there are no known instances where these relocations are being referenced at run-time. Failing due to these bad relocations causes otherwise functional programs to not load. Therefore these bad relocations will be ignored

[jackcmay]

Found a use-case that recreates this issue. In libstd's panic! macro the file, line, and column are passed as a triple. The triple is stored in the .data.rel.ro section as (ptr to a string, size as u64, line as u64 number, column number as u64). The ptr to a string is currently zero when instead it should contain a file offset to the string in the .rodata section and used during relocation to fixup the pointer to string to point to the final virtual address. Why the ptr to string is zero looks to be a question for the linker. Next step dig into the linker to find out why zero is written.