4 ms·
Not knowing anything about ARM, I didn't get how this bit is supposed to work: We enforce this rule by restricting the sorts of operations that progra
by nickzoic 16y ago
Not knowing anything about ARM, I didn't get how this bit is supposed to work:
We enforce this rule by restricting the sorts of operations that
programs can use to alter sp. Programs can alter sp by adding or
subtracting an immediate, as a side-effect of a load or store:
ldr rX, [sp], #4! ; loads from stack, then adds 4 to sp
These are safe because, as we mentioned before, the largest
immediate available in a load or store is ±4095. Even after adding or
subtracting 4095, the stack pointer will still be within the sandbox or
guard regions.
I get the idea of the guard protecting against the biggest immediate offset, but what stops me doing an SP-updating LDR with a big offset multiple times, pushing SP beyond my "safe" memory segment?
EDIT: I guess I might be taking:
Any other operation that alters sp must be followed by a guard
instruction.
too precisely, and you could just follow every ldr which writes back SP with a BIC too. Maybe I'm missing the point.
EDIT2: Wait, wait, I get it now. Once the stack pointer is in the guard area, the CPU faults if you do another LDR. Don't mind me!
- jbri 16y agoBecause you'll fault in the guard zone on one of those memory accesses, and then your app will get killed. EDIT: No, you don't need to check after a stack memory access either. The farthest you can get out of the sandbox is an access-then-adjust of 4095 bytes, followed by an adjust-then-access of 4095 bytes, which means you access the very tail end (offset 8190) of the guard zone, fault, and die.
- nickzoic 16y agoThanks, I just realized that ... duh. I'd been imagining the guard regions as a "passive guard", eg: an area where nothing important is, rather than as an "active guard", eg: where you fault if you read/write.