zlacker

[return to "OpenBSD: Removing syscall(2) from libc and kernel"]
1. __turb+3l[view] [source] 2023-10-27 17:00:14
>>eclipt+(OP)
It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.

I wonder if there could be some way to sign a dynamic library to allow it to create direct system calls and then pass that as a kernel command line argument at boot?

◧◩
2. maskli+Sp[view] [source] 2023-10-27 17:24:12
>>__turb+3l
> It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.

Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems.

But as usual, go is uniquely american, only doing the right thing after it has tried everything else.

◧◩◪
3. tadfis+qt[view] [source] 2023-10-27 17:39:42
>>maskli+Sp
You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?
◧◩◪◨
4. maskli+du[view] [source] 2023-10-27 17:45:23
>>tadfis+qt
> You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI)

No, you could not.

On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc.

And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.

◧◩◪◨⬒
5. clhoda+jU1[view] [source] 2023-10-28 04:01:47
>>maskli+du
It's not about hardcoding, it's about the fact that libc isn't even an ABI, really. It's a C source API, which compiles down to a secret ABI that you can't know (you just have to expand all the macros and see what you get). That's sort of OK if every compiled program in the world is written in C, but as soon as you want to start writing in another language it kind of falls apart.
[go to top]