3 ms·
But surely applications can make syscalls directly without invoking libc at all, by setting up the registers directly and directly executing the processor instr
by quietbritishjim 7y ago
But surely applications can make syscalls directly without invoking libc at all, by setting up the registers directly and directly executing the processor instruction that causes the right software interrupt? In which case the parent comment's point still stands: you can bypass checking that's at the libc level in a way you can't bypass checking within the kernel.
- saagarjha 7y agoNo, because the calling address would be wrong.
- jacquesm 7y agoWhy? After all, if libc is optional then you could simply provide a statically linked binary and be done with it, there would be no way to change the addresses.
- throwaway2048 7y agoIf you can provide a staticly linked binary, its already game over as far as these protections are concerned. They are designed as a protection against stuff like ROP and other memory based, zero information attacks that hit already running processes.
- saagarjha 7y agoIf you link against libc, that’s the only place you can enter the kernel from. If you statically link that is relaxed to “system calls can come from anywhere on your code”. The former has stronger protections, obviously, but as far as I can tell you still have protection from “wild shellcode in a RWX region can make syscalls”.
- throwaway2048 7y agoShould be noted, that by default on OpenBSD, an RWX page is impossible, mprotect() will fail and the process will get killed trying.
- saagarjha 7y agoSurely there is an “out” for JITs that have not yet adopted W^X?
- tedunangst 7y agoAn opt in actually, to request looser checks.
- lostmsu 7y agoCan't you make page temporarily RW, JIT, then switch back to RX?
- saagarjha 7y agoYou can, but the application needs to support this.