Making stinkarm stink less, or more?

Making stinkarm stink way less, or more? | xnacly - blogMaking stinkarm stink way less, or more? Aug 16, 2026 2321 Words 11 Minute read

Tags: Arm Rust

Its been a while, but about half a year ago I wrote an article about implementing a userspace armv7 emulator from scratch, meaning I implemented: ARMASM 1 .section .rodata 2msg: 3 .asciz "Hello, world!\n" 5 .section .text 6 .global _start 7_start: 8 ldr r0, =1 9 ldr r1, =msg 10 mov r2, #14 11 mov r7, #4 12 svc #0 13 14 mov r0, #0 15 mov r7, #1 16 svc #0 Or as a list: elf(32) parsing, validation and interpretation decoding of a very small subset of armv7 instructions (only 3) executing said instructions, even conditional ones 🤓 translating memory access from the guest into the host syscall forwarding (from armv7 to x86) syscall sandboxing (only a restricted syscall subset) and denying syscall execution Do read Building a Minimal Viable Armv7 Emulator from Scratch, since this post doesnt go as deep into detail as the previous one (It’s my first article in 3 months I had enough motivation for writing :O). This is partially an update, partially my toughts on decoding and emulating armv7-a and also a bit of a devlog. Overly complex host to guest mem translation On the first article, ~aengelke on lobste.rs, had some comments, the one resonating the most was: [&mldr;] The Mem indirection seems pretty inefficient. When emulating 32-bit platforms on a 64-bit system, just mmap a 4 GiB region, the translation then becomes a single addition. Otherwise, having a small hash table of recently translated address regions can avoid more expensive searches – memory accesses have a very high locality. The number of mappings is usually small, so binary search over a sorted array is simpler than a B-tree. [&mldr;]

So now i figured, why not improve on my implementation a bit, first with replacing the complex allocation region based tracking with just allocating a 4gig slab in memory for the guest, mapping the process regions there and handing out pointers into that region to the guest. So, previously the memory translation worked as follows: One takes a binary tree map of a guest starting addr to its host segment RUST 1struct MappedSegment { 2 host_ptr: *mut u8, 3 len: u32, 4} 6pub struct Mem { 7 maps: BTreeMapu32, MappedSegment>, 8}

On ask for a region handout, specifically on mapping ELF segments with a starting addr, map_region is called: RUST 1// in stinkarm::elf::pheader::Pheader::map: 3// record mapping in guest memory table, so CPU can translate guest vaddr to host pointer 4guest_mem.map_region(self.vaddr, len, segment_ptr); 6// in stinkarm::mem::Mem: 8pub fn map_region(&mut self, guest_addr: u32, len: u32, host_ptr: *mut u8) { 9 self.maps 10 .insert(guest_addr, MappedSegment { host_ptr, len }); 11}

Since the cpu needs to fetch an instruction, there is read_u32, calling translate: RUST 1/// translate a guest addr to a host addr we can write and read from 2pub fn translate(&self, guest_addr: u32) -> Optionmut u8> { 3 // Find the greatest key 4 let (&base, seg) = self.maps.range(..=guest_addr).next_back()?; 5 if guest_addr base.wrapping_add(seg.len) { 6 let offset = guest_addr.wrapping_sub(base); 7 Some(unsafe { seg.host_ptr.add(offset as usize) }) 8 } else { 9 None 10 } 11} 12 13pub fn read_u32(&self, guest_addr: u32) -> Optionu32> { 14 let ptr = self.translate(guest_addr)?; 15 unsafe { Some(u32::from_le(*(ptr as *const u32))) } 16} 17 18 19// in stinkarm::cpu::Cpu: 20 21pub fn step(&mut self) -> Resultbool, err::Err> { 22 let Some(word) = self.mem.read_u32(self.pc()) else { 23 return Ok(false); 24 }; 25 26 // [...] 27}

Of course this totally unnecessary work, we dont need to keep track of every mapping/allocation/region by walking their ranges, we only need to make sure the R/W interaction request is within bounds. Thus the new implementation is: One takes a pointer and a size: RUST 1pub struct Mem { 2 ptr: NonNullu8>, 3 len: usize, 4}

When asked to map ELF segments, stinkarm::mem::Mem::map_region is called: RUST 1// in stinkarm::elf::pheader::Pheader::map: 2guest_mem.map_region(self.vaddr, file_slice)?; 4// in stinkarm::mem::Mem: 6pub fn map_region(&mut self, guest_addr: u32, data: &[u8]) -> Result(), String> { 7 let dst = self 8 .get_slice_mut(guest_addr, data.len()) 9 .ok_or_else(|| format!("guest region out of bounds at {guest_addr:#010x}"))?; 10 dst.copy_from_slice(data); 11 Ok(()) 12}

When cpu requests a dword for decoding, it does so by invoking stinkarm::mem::Mem::read32, just as before, only this time with bounds checks: RUST 1pub fn read_u32(&self, guest_addr: u32) -> Optionu32> { 2 let bytes = self.get_slice(guest_addr, 4)?; 3 Some(u32::from_le_bytes(bytes.try_into().unwrap())) 4} 6fn get_slice(&self, guest_addr: u32, len: usize) -> Option[u8]> { 7 if !self.in_bounds(guest_addr, len) { 8 return None; 9 } 10 11 Some(unsafe { std::slice::from_raw_parts(self.ptr.as_ptr().add(guest_addr as usize), len) }) 12}

Hardening the existing implementation I...

Making stinkarm stink less, or more?

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills