5 ms·
Why not just go all the way and separate the program instruction memory from the data memory, physically? I know there’s an approximation of this at the page le
by dcow 2y ago
Why not just go all the way and separate the program instruction memory from the data memory, physically? I know there’s an approximation of this at the page level, but why even let the kernel modify its own memory in the first place? Memory unit that only loads signed pages. etc.
- pdpi 2y agoWhat you're asking for is a Harvard architecture computer (as opposed to a von Neumann architecture). There's tradeoffs involved. Two things to keep in mind are that JITs are damn useful pieces of tech, so losing them is a pretty damn heft price to pay for that separation, and interpreters will still treat your data memory as program instruction memory, which limits the benefit.
- dcow 2y agoI know. My question is rhetorical. In a world where the only way to secure a VN machine is to reboot it every X seconds, at what point is reboot frequency so high that you might as well accept slower interpreters if it means you don’t have to reboot all the time? Or you run the kernel under a hypervisor and control the page security that way. JIT becomes a heavily scrutinized process between the kernel and hypervisor. JITed code is only ever executed in a clean address space. Etc. All the things browsers and kernels do poorly today.
- astrange 2y agoWhat is this a response to? This already happens though - the kernel can't modify its own code pages. But there are plenty remaining attacks like overwriting function pointers or other data.
- dcow 2y agoIf you can’t modify kernel memory then how do you overwrite function pointers? (I understand how rop works.) At some level you have to get privileged execution and doing so would be incredibly difficult if you can’t trick the kernel at some point after whatever amount of ropping you’ve done.
- saagarjha 2y agoThis is how iOS works already.