3 ms·
A question about using this call: Chrome is the one who wants it. But you can’t unmap sealed pages because an attacker could then re-map them with different fl
by MBCook 2y ago
A question about using this call:
Chrome is the one who wants it. But you can’t unmap sealed pages because an attacker could then re-map them with different flags.
So that basically means this can never be used on pages allocated at runtime unless you intend to hold them for the entire process lifetime, right?
Doesn’t that mean it can’t be used for all the memory used by, say, the JS sandbox which would be a very very tempting target?
Or is the idea that you deal with this by always running that kind of stuff in a different process where you can seal the memory and then you can just kill the process when you’re done?
I’m not familiar with how Chrome manages memory/processes, so I’m not exactly sure why this wouldn’t be an issue.
Is this also the reason why the articles about this often mention it’s not useful to most programs (outside of how memory is set up at processes start up)?
- PhilipRoman 2y ago>Doesn’t that mean it can’t be used for all the memory used by, say, the JS sandbox which would be a very very tempting target? Multiprocessing is an option here. I think chrome uses it extensively, so that might be the play here. You need separate processes for other stuff anyway, like isolation via namespaces.
- masklinn 2y agoYes, in fact in his comments Theo de Raadt specifically says (amongst other things): > experience with mimmutable() says that applications don't do any of it themselves, it is all in execve(), libc initialization, and ld.so. So this is almost never something a process does to itself, it is part of the sandboxing of child processes.