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. FullyF+dX[view] [source] 2023-10-27 20:16:52
>>maskli+Sp
I don't use Go, but I had the exact same reaction; C is the source of most of the problems and this is just codifies the use of C. The whole thing has a security by obscurity smell.
◧◩◪◨
4. MrRoll+vc1[view] [source] 2023-10-27 21:35:19
>>FullyF+dX
Your comment seems to conflate a language with an ABI. To what end? What is inherently insecure about the C ABI? Why is using a syscall interface any more secure?
[go to top]