Miod Vallat <[email protected]> wrote: > > For dynamic binaries, valid regions are ld.so's text segment, the signal > > trampoline, and libc.so's text segment... AND the main program's text. > > > > Unfortunately our current go build model hasn't followed solaris/macos > > approach yet of calling libc stubs, and uses the inappropriate "embed > > system calls directly" method, so for now we'll need to authorize the main > > program text as well. A comment in exec_elf.c explains this. > > > > If go is adapted to call library-based system call stubs on OpenBSD as > > well, this problem will go away. There may be other environments creating > > raw system calls. I guess we'll need to find them as time goes by, and > > hope in time we can repair those also. > > Or you could use an ELF note to flag binaries allowed to issue syscalls > from their text section: only static binaries (including ld.so) and go > binaries would need them.
Imagine a ld.so without the flag. The kernel starts a userland process running there. So ld.so must be able to issue system calls Imagine a static binary without the flag. It would fail. The kernel can alreayd identify these circumstances, and does not need a flag. The only special case is libc.so. We discussed adding a linker option to add a note to libc. And then build tooling to add the flag for libc. And then ld.so identification of this note. But does it actually matter which way this is done? I fear the option would be abused for other purposes. In the future, why would we want programs doing system calls from other segments? Are there any legitimate compelling reasons to avoid calling the libc stubs? I don't believe so. Especially if those segments are in network facing programs and/or generated on the fly. At worst a nasty JIT can generate code to call & of libc syscall(2) stub with SYS_* symbolic names. That approach remains simple and workable for the developer, but somewhat more difficult for an attacker who not know the relevant locations.
