6 ms·

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

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?

CHY872 3y ago
OpenBSD’s position is far from unique. It’s shared with MacOS (and iOS).
- steveklabnik 3y ago
  And Windows, in a sense: not that libc is the interface, but that the assembly-level API is not the interface.
  - pjmlp 3y ago
    And almost every other OS still in use today, what Linux does is reminiscent from OSes like CP/M and MS-DOS.
    - monocasa 3y ago
      And seL4.
- masklinn 3y ago
  And windows. And that's just the platforms which technically enforce it. Linux is essentially the only platform which actually supports raw syscalls, in the sense that it's considered a normal system API.
irdc 3y ago
> 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? That sounds like an additional knob to tweak. The OpenBSD project is famously opposed to such knobs.
matheusmoreira 3y ago
OpenBSD is certainly taking it quite far. They want to disallow system calls from all non-libc code segments so that only whitelisted code can interface with it. It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface. I've written somewhat at length about this: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls
- masklinn 3y ago
  FWIW your website is unusable on desktop: the font is unreadably huge. And while Firefox's reader mode does seem to mitigate the issue correctly, Safari's cuts off at the second paragraph.
  - matheusmoreira 3y ago
    Thank you. I'll try to fix it. I gotta get better at this.
  - matheusmoreira 3y ago
    I reduced the font size to 24px. Does it read better despite the margins? I appreciate the feedback. My intention was to maximize the use of space with big fonts even on the desktop but there's no point if the resulting text is unreadable.
    - matheusmoreira 3y ago
      Improved the look of the site as well while I was at it.
- deleted 3y ago
  [deleted]
- LegionMammal978 3y ago
  > It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface. It's wrong to say that Linux stands alone in having a stable syscall interface. FreeBSD [0] and NetBSD [1] both retain syscall compatibility for old binaries (the former apparently with some exceptions permitted); DragonFly BSD also appears to keep old syscalls in place. In fact, I only know of Windows, OpenBSD, and presumably macOS as mainstream desktop OSes without mostly-stable syscalls. [0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily [1] https://www.netbsd.org/docs/internals/en/chap-processes.html#syscall_versioning https://www.netbsd.org/docs/internals/en/chap-processes.html...
masklinn 3y ago
> 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.
- PrimeMcFly 3y ago
  > go is uniquely american, doing the right thing after it has tried everything else. That doesn't seem like anything common to an American way of doing things. What an odd statement.
  - kstrauser 3y ago
    It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternatives/ https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
    - arp242 3y ago
      Bizarre nationalistic "they're doing it because they're Americans" rantings are still not okay even if they're a "play on a quote". I can "play" with all sorts of quotes to say all sorts of idiotic things.
      - kstrauser 3y ago
        I guess. I'm proudly American and I thought it was funny, but everyone has different tolerances.
- tadfisher 3y ago
  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?
bregma 3y ago
What about OSes that are not built around monolithic kernels and the syscall() paradigm?
saagarjha 3y ago
I am sure Cosmopolitan is going to love this change.
- masklinn 3y ago
  I would assume they already have ways to bounce through a dynamically linked system library since cosmopolitan works on macos, and even more so windows.
  - Conscat 3y ago
    That's true, but it's a point of pride in Cosmo's marketing that it produces statically linked binaries acroscreate, least several operating systems. It can dynamically link the system32 DLLs in Windows and probably could OpenBSD's crt, but dynamic linking in general doesn't work. `dlopen` is no-op, and this has made Cosmo graphics extremely difficult so far.
    - actionfromafar 3y ago
      Is that a self-imposed limitation? It sounds eminently possible to add some kind of work-around for dynamic linking. Maybe not for a general case, but for creating a GUI for instance.
      - Conscat 3y ago
        Yes, there actually is a to-be merged fork of Cosmopolitan that makes Dear ImGui work, but no dynamic linking is generally a big limitation for GPU acceleration.
blueflow 3y ago
> OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel Which is a reasonable thing, given that the libc interface is defined by a widely used IEEE standard while the kernel interface is not.
- Conscat 3y ago
  libC is an extremely leaky abstraction. Programming to it assumes you have a runtime that supports constructor functions, POSIX errno and locale, a global heap allocator singleton, and more. The design space of _Hello World_ is massively constrained by libC.
LanzVonL 3y ago
[dead]

CHY872 3y ago

OpenBSD’s position is far from unique. It’s shared with MacOS (and iOS).

steveklabnik 3y ago
And Windows, in a sense: not that libc is the interface, but that the assembly-level API is not the interface.
- pjmlp 3y ago
  And almost every other OS still in use today, what Linux does is reminiscent from OSes like CP/M and MS-DOS.
  - monocasa 3y ago
    And seL4.
masklinn 3y ago
And windows. And that's just the platforms which technically enforce it. Linux is essentially the only platform which actually supports raw syscalls, in the sense that it's considered a normal system API.

irdc 3y ago

> 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? That sounds like an additional knob to tweak. The OpenBSD project is famously opposed to such knobs.

matheusmoreira 3y ago

OpenBSD is certainly taking it quite far. They want to disallow system calls from all non-libc code segments so that only whitelisted code can interface with it. It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface. I've written somewhat at length about this: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls

masklinn 3y ago
FWIW your website is unusable on desktop: the font is unreadably huge. And while Firefox's reader mode does seem to mitigate the issue correctly, Safari's cuts off at the second paragraph.
- matheusmoreira 3y ago
  Thank you. I'll try to fix it. I gotta get better at this.
- matheusmoreira 3y ago
  I reduced the font size to 24px. Does it read better despite the margins? I appreciate the feedback. My intention was to maximize the use of space with big fonts even on the desktop but there's no point if the resulting text is unreadable.
  - matheusmoreira 3y ago
    Improved the look of the site as well while I was at it.
deleted 3y ago
[deleted]
LegionMammal978 3y ago
> It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface. It's wrong to say that Linux stands alone in having a stable syscall interface. FreeBSD [0] and NetBSD [1] both retain syscall compatibility for old binaries (the former apparently with some exceptions permitted); DragonFly BSD also appears to keep old syscalls in place. In fact, I only know of Windows, OpenBSD, and presumably macOS as mainstream desktop OSes without mostly-stable syscalls. [0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily [1] https://www.netbsd.org/docs/internals/en/chap-processes.html#syscall_versioning https://www.netbsd.org/docs/internals/en/chap-processes.html...

masklinn 3y ago

> 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.

PrimeMcFly 3y ago
> go is uniquely american, doing the right thing after it has tried everything else. That doesn't seem like anything common to an American way of doing things. What an odd statement.
- kstrauser 3y ago
  It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternatives/ https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
  - arp242 3y ago
    Bizarre nationalistic "they're doing it because they're Americans" rantings are still not okay even if they're a "play on a quote". I can "play" with all sorts of quotes to say all sorts of idiotic things.
    - kstrauser 3y ago
      I guess. I'm proudly American and I thought it was funny, but everyone has different tolerances.
tadfisher 3y ago
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?

bregma 3y ago

What about OSes that are not built around monolithic kernels and the syscall() paradigm?

saagarjha 3y ago

I am sure Cosmopolitan is going to love this change.

masklinn 3y ago
I would assume they already have ways to bounce through a dynamically linked system library since cosmopolitan works on macos, and even more so windows.
- Conscat 3y ago
  That's true, but it's a point of pride in Cosmo's marketing that it produces statically linked binaries acroscreate, least several operating systems. It can dynamically link the system32 DLLs in Windows and probably could OpenBSD's crt, but dynamic linking in general doesn't work. `dlopen` is no-op, and this has made Cosmo graphics extremely difficult so far.
  - actionfromafar 3y ago
    Is that a self-imposed limitation? It sounds eminently possible to add some kind of work-around for dynamic linking. Maybe not for a general case, but for creating a GUI for instance.
    - Conscat 3y ago
      Yes, there actually is a to-be merged fork of Cosmopolitan that makes Dear ImGui work, but no dynamic linking is generally a big limitation for GPU acceleration.

blueflow 3y ago

> OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel Which is a reasonable thing, given that the libc interface is defined by a widely used IEEE standard while the kernel interface is not.

Conscat 3y ago
libC is an extremely leaky abstraction. Programming to it assumes you have a runtime that supports constructor functions, POSIX errno and locale, a global heap allocator singleton, and more. The design space of _Hello World_ is massively constrained by libC.

LanzVonL 3y ago

[dead]