6 ms·

Stuff like this is why I'm supportive of newer languages like Go and Zig that sidestep libc entirely (when not using cgo as in TFA of course). libc is a great a

Stuff like this is why I'm supportive of newer languages like Go and Zig that sidestep libc entirely (when not using cgo as in TFA of course). libc is a great achievement and has served us well but, boy, it sure is a product of its time. `errno` is another relic that needs to die yesterday.

eatonphil 3y ago
Depending on the operating system, you can't skip libc even in Go. I think it's required on openbsd and illumos/solaris for example. https://utcc.utoronto.ca/~cks/space/blog/programming/Go116OpenBSDUsesLibc https://utcc.utoronto.ca/~cks/space/blog/programming/Go116Op...
- favorited 3y ago
  golang used to break all the time on macOS, because it was using the syscall ABI, which isn't stable, instead of libSystem, which is.
  - dottedmag 3y ago
    It has been fixed recently-ish.
    - littlestymaar 3y ago
      A long time ago, but AFAIK the fix was “use the system's libc”.
    - bananapub 3y ago
      it was fixed by using-the-system-libs
    - eatonphil 3y ago
      Could you link to the fix or their docs on it? I.e. what do they do today?
      - favorited 3y ago
        The comments on this GitHub issue include links to the changes in the golang code review system: https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490
- beebmam 3y ago
  I think it's the same in Windows, right? Can't use the syscalls underneath the hood, everything through the standard libraries. Maybe I'm wrong (I know very little about Windows other than how to use it to play games, and WSL)
  - roblabla 3y ago
    On windows it’s somewhat possible to avoid most of it by linking to ntdll, which only provides symbols for raw syscall wrappers. But a lot of it is unstable and may change from a windows release to the next. Doing raw syscalls without ntdll is also possible, but windows syscall numbers change on essentially every release, so you’d end up with something that only works on your windows version.
  - ynik 3y ago
    The standard libraries on Windows don't involve libc. The Windows APIs look rather different, and in general are much more friendly to multi-threading. POSIX on the other hand tends to assume that the program is in control of everything happening inside of it, which is an incorrect assumption due to libraries. In this particular case, the Windows APIs have neither getaddrinfo() nor getenv(); and the closest equivalent GetEnvironmentVariableW is perfectly thread-safe. Microsoft additionally has a C runtime (msvcrt) providing functions like getenv(), but this is much less fundamental than it is on other system. Every program is supposed to ship its own copy of the C runtime, it's not officially part of Windows! And it's perfectly possible for multiple different copies of the C runtime to be loaded into the same Windows process. And since *environ is a variable defined by the C runtime, there's a different copy for each C runtime...
    - pjmlp 3y ago
      Almost correct, except that since Windows 10 there is now a C runtime shipped as standard, ironically it is actually written in C++ taking advantage of its safety features over plain C, and exposing the C API via extern "C". https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170 https://learn.microsoft.com/en-us/cpp/windows/universal-crt-...
signa11 3y ago
> `errno` is another relic that needs to die yesterday. ok, i will bite: what is the problem with it ?
- ForkMeOnTinder 3y ago
  It's global state for a local condition. Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html
  - signa11 3y ago
    > ... Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html yes, he argues against its usage in the KERNEL.
    - Cloudef 3y ago
      But his argument stands even outside the kernel. Errno is awful, similar to locale APIs.
- burntsushi 3y ago
  Shared global (well, thread local) mutable state. As for why shared global mutable state is (generally) bad, see: https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil https://softwareengineering.stackexchange.com/questions/1481... `man 3 errno` on my Linux system even has a note calling out a common failure pattern. Can you spot the problem? if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } }
  - j16sdiz 3y ago
    What's the alternative? Returning a"Result" struct doubles the size. This is one less register to use. Exception handling is even more invasive. They are great for high(-er) level language, but less prefect on lower level where performance is critical. EDIT: Linux kernel use negative return value for error. It's good and efficient when it work. But it is not always an option when you need the full register width
silisili 3y ago
We've been building everything with CGO_ENABLED=0 for years now, with no nasty side effects. It gets to be a pain using the default, when something as innocuous as a point version of a Docker image breaks compatibility because of a glibc version change[1]. [1] golang official image 1.20.4 to 1.20.5 went from Debian 11 to 12 base. Always use the -(debian version) tags.
- X-Istence 3y ago
  Split DNS is broken on macOS when doing that, and for users with VPN that does split DNS it is not just an annoyance it leads to software not actually functioning. Re-implementing system capabilities is fine and all as long as you support common use cases properly, which Golang does not.
  - DominoTree 3y ago
    And on the flip side, there have been a number of instances where, in cases where the behavior differs, the Golang documentation describes a function only as it behaves with the Golang-native implementation, rather than the system implementation which ends up being the default - without calling any of this out
throwaway894345 3y ago
Yeah, there's so much misery in the C ecosystem that it's better to eschew it altogether. Even merely packaging anything that depends on C ends up being a hugely painful undertaking since every C library has its own bespoke build system and its own implicit set of dependencies (and implicit versions of those dependencies, and expectations about where on the system those dependencies live). I mostly like C as a language, but between the security concerns and the tooling concerns (and the community's zealous devotion to ignoring these very real problems) I'm really excited for its increasing marginalization. Unfortunately, it's not being marginalized in favor of "a better C", but rather every ecosystem is rewriting the same stuff from scratch which seems like a bit of a bummer (but still better than depending on C).
- hulitu 3y ago
  > since every C library has its own bespoke build system and its own implicit set of dependencies (and You should see other libraries. At least glibc does not require meson, cmake and ninja.
  - techbrovanguard 3y ago
    yes, it only requires autotools. a build system so friendly that it spawned cmake and meson to replace it.
deleted 3y ago
[deleted]
cookiengineer 3y ago
Most of the still working privilege escalation exploits from 2006 are only still there because it is intended behaviour of glibc. Environment variables like LD_PRELOAD should never ever be available in production. I totally understand why the muslc developers kinda freaked out and started their own standard library.
- avereveard 3y ago
  Err no thank you. Ld preload and similar mechanism are great to inject code into apps legitimately, i.e. to patch long unsupported systems or to tame current ones. For example I have vision issue and without reshade filter I would be unable to play a great deal of games. Now that is also an attack vector, that's for sure, but you cannot go ax features willy nilly just because you don't see value in them.
  - djbusby 3y ago
    Chestersons Fence https://en.m.wiktionary.org/wiki/Chesterton%27s_fence https://en.m.wiktionary.org/wiki/Chesterton%27s_fence
  - nine_k 3y ago
    LD_PRELOAD won't be needed if the OS were built around containers / jails, instead of the weakly isolated processes and process groups. The Unix kernel (both Linux, BSD, and Solaris) already had much of what's needed, say, 30 years ago, but nobody saw it as such a burning necessity (likely except Solaris which eventually developed Zones).
    - hulitu 3y ago
      On a "normal" desktop system, you don't need containers or jails. Your programs must communicate with each other (copy paste, print screen, etc.). But today every god damn UI program needs an internet connection to phone home and execute remote code. This is the actual problem which must be fixed.
    - gpderetta 3y ago
deleted 3y ago
[deleted]

eatonphil 3y ago

Depending on the operating system, you can't skip libc even in Go. I think it's required on openbsd and illumos/solaris for example. https://utcc.utoronto.ca/~cks/space/blog/programming/Go116OpenBSDUsesLibc https://utcc.utoronto.ca/~cks/space/blog/programming/Go116Op...

favorited 3y ago
golang used to break all the time on macOS, because it was using the syscall ABI, which isn't stable, instead of libSystem, which is.
- dottedmag 3y ago
  It has been fixed recently-ish.
  - littlestymaar 3y ago
    A long time ago, but AFAIK the fix was “use the system's libc”.
  - bananapub 3y ago
    it was fixed by using-the-system-libs
  - eatonphil 3y ago
    Could you link to the fix or their docs on it? I.e. what do they do today?
    - favorited 3y ago
      The comments on this GitHub issue include links to the changes in the golang code review system: https://github.com/golang/go/issues/17490 https://github.com/golang/go/issues/17490
beebmam 3y ago
I think it's the same in Windows, right? Can't use the syscalls underneath the hood, everything through the standard libraries. Maybe I'm wrong (I know very little about Windows other than how to use it to play games, and WSL)
- roblabla 3y ago
  On windows it’s somewhat possible to avoid most of it by linking to ntdll, which only provides symbols for raw syscall wrappers. But a lot of it is unstable and may change from a windows release to the next. Doing raw syscalls without ntdll is also possible, but windows syscall numbers change on essentially every release, so you’d end up with something that only works on your windows version.
- ynik 3y ago
  The standard libraries on Windows don't involve libc. The Windows APIs look rather different, and in general are much more friendly to multi-threading. POSIX on the other hand tends to assume that the program is in control of everything happening inside of it, which is an incorrect assumption due to libraries. In this particular case, the Windows APIs have neither getaddrinfo() nor getenv(); and the closest equivalent GetEnvironmentVariableW is perfectly thread-safe. Microsoft additionally has a C runtime (msvcrt) providing functions like getenv(), but this is much less fundamental than it is on other system. Every program is supposed to ship its own copy of the C runtime, it's not officially part of Windows! And it's perfectly possible for multiple different copies of the C runtime to be loaded into the same Windows process. And since *environ is a variable defined by the C runtime, there's a different copy for each C runtime...
  - pjmlp 3y ago
    Almost correct, except that since Windows 10 there is now a C runtime shipped as standard, ironically it is actually written in C++ taking advantage of its safety features over plain C, and exposing the C API via extern "C". https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170 https://learn.microsoft.com/en-us/cpp/windows/universal-crt-...

signa11 3y ago

> `errno` is another relic that needs to die yesterday. ok, i will bite: what is the problem with it ?

ForkMeOnTinder 3y ago
It's global state for a local condition. Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html
- signa11 3y ago
  > ... Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html yes, he argues against its usage in the KERNEL.
  - Cloudef 3y ago
    But his argument stands even outside the kernel. Errno is awful, similar to locale APIs.
burntsushi 3y ago
Shared global (well, thread local) mutable state. As for why shared global mutable state is (generally) bad, see: https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil https://softwareengineering.stackexchange.com/questions/1481... `man 3 errno` on my Linux system even has a note calling out a common failure pattern. Can you spot the problem? if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } }
- j16sdiz 3y ago
  What's the alternative? Returning a"Result" struct doubles the size. This is one less register to use. Exception handling is even more invasive. They are great for high(-er) level language, but less prefect on lower level where performance is critical. EDIT: Linux kernel use negative return value for error. It's good and efficient when it work. But it is not always an option when you need the full register width

silisili 3y ago

We've been building everything with CGO_ENABLED=0 for years now, with no nasty side effects. It gets to be a pain using the default, when something as innocuous as a point version of a Docker image breaks compatibility because of a glibc version change[1]. [1] golang official image 1.20.4 to 1.20.5 went from Debian 11 to 12 base. Always use the -(debian version) tags.

X-Istence 3y ago
Split DNS is broken on macOS when doing that, and for users with VPN that does split DNS it is not just an annoyance it leads to software not actually functioning. Re-implementing system capabilities is fine and all as long as you support common use cases properly, which Golang does not.
- DominoTree 3y ago
  And on the flip side, there have been a number of instances where, in cases where the behavior differs, the Golang documentation describes a function only as it behaves with the Golang-native implementation, rather than the system implementation which ends up being the default - without calling any of this out

throwaway894345 3y ago

Yeah, there's so much misery in the C ecosystem that it's better to eschew it altogether. Even merely packaging anything that depends on C ends up being a hugely painful undertaking since every C library has its own bespoke build system and its own implicit set of dependencies (and implicit versions of those dependencies, and expectations about where on the system those dependencies live). I mostly like C as a language, but between the security concerns and the tooling concerns (and the community's zealous devotion to ignoring these very real problems) I'm really excited for its increasing marginalization. Unfortunately, it's not being marginalized in favor of "a better C", but rather every ecosystem is rewriting the same stuff from scratch which seems like a bit of a bummer (but still better than depending on C).

hulitu 3y ago
> since every C library has its own bespoke build system and its own implicit set of dependencies (and You should see other libraries. At least glibc does not require meson, cmake and ninja.
- techbrovanguard 3y ago
  yes, it only requires autotools. a build system so friendly that it spawned cmake and meson to replace it.

deleted 3y ago

[deleted]

cookiengineer 3y ago

Most of the still working privilege escalation exploits from 2006 are only still there because it is intended behaviour of glibc. Environment variables like LD_PRELOAD should never ever be available in production. I totally understand why the muslc developers kinda freaked out and started their own standard library.

avereveard 3y ago
Err no thank you. Ld preload and similar mechanism are great to inject code into apps legitimately, i.e. to patch long unsupported systems or to tame current ones. For example I have vision issue and without reshade filter I would be unable to play a great deal of games. Now that is also an attack vector, that's for sure, but you cannot go ax features willy nilly just because you don't see value in them.
- djbusby 3y ago
  Chestersons Fence https://en.m.wiktionary.org/wiki/Chesterton%27s_fence https://en.m.wiktionary.org/wiki/Chesterton%27s_fence
- nine_k 3y ago
  LD_PRELOAD won't be needed if the OS were built around containers / jails, instead of the weakly isolated processes and process groups. The Unix kernel (both Linux, BSD, and Solaris) already had much of what's needed, say, 30 years ago, but nobody saw it as such a burning necessity (likely except Solaris which eventually developed Zones).
  - hulitu 3y ago
    On a "normal" desktop system, you don't need containers or jails. Your programs must communicate with each other (copy paste, print screen, etc.). But today every god damn UI program needs an internet connection to phone home and execute remote code. This is the actual problem which must be fixed.
  - gpderetta 3y ago

deleted 3y ago

[deleted]