4 ms·
Yes, I'd like the OpenBSD approach a lot more if the specially privileged syscall library was a language-agnostic library just for syscalls instead of libc. Al
by mike_hock 3y ago
Yes, I'd like the OpenBSD approach a lot more if the specially privileged syscall library was a language-agnostic library just for syscalls instead of libc.
Also, if you're gonna add new ELF sections anyway, why not do syscall "relocation" directly (with a similar randomization like ASLR) instead of going through stubs? This "relocation" doesn't actually need to change any memory or use any offset tables since the syscall numbers are a farce under the new system anyway. Just make it a map of the location of syscall instructions to implied syscall numbers. Once you've phased out the old syscall model, you can even repurpose RAX as an additional syscall parameter.
- Someone 3y ago> I'd like the OpenBSD approach a lot more if the specially privileged syscall library was a language-agnostic library just for syscalls instead of libc. I think they should split that part of, too. Such a split would better reflect the split of responsibilities between kernel maintainers and libc maintainers. At the same the effective difference for people using the code is minute. Any decent linker will strip out unused functions in libraries you link with, so if you currently only use the part of libc that would become “libsyscall”, the end effect would be the same as when “libsyscall” existed.