6 ms·

I hope one day that I can statically link against my libc easily one day. Not just statically link but even LTO my libc into my binary. I understand the "securi

I hope one day that I can statically link against my libc easily one day. Not just statically link but even LTO my libc into my binary. I understand the "security" concerns, but I feel there are cases where they don't matter. Case in point; my C compiler. It already was not designed to handle untrusted input well enough and I plan to run multiple instances in parallel, so my kernel should handle COW.

yjftsjthsd-h 5y ago
You can do this today with musl, FWIW.
- ndesaulniers 5y ago
  You can, and I have done it. It's easy for hello world. But for larger projects it's more difficult. If anyone has even done a build of clang with this, I'd love to know!
  - boogies 5y ago
    > If anyone has even done a build of clang with this, I'd love to know! Clang's in Alpine Linux's repo's, so I guess they have and this is how: https://git.alpinelinux.org/aports/tree/main/clang https://git.alpinelinux.org/aports/tree/main/clang
    - Aissen 5y ago
      They built clang against musl, just not statically.
  - Ericson2314 5y ago
    I made https://github.com/NixOS/nixpkgs/pull/149523 https://github.com/NixOS/nixpkgs/pull/149523 to kick off nix-build -A pkgsStatic.llvmPackages.clang-unwrapped Which built all the other deps just fine, but failed buildling LLVM with CONFIGURE_LLVM_NATIVE. That seems easy enough to fix, as that's the regular part, though. No guarantee there wouldn't be other more serious issues lurking beneath, but we've attempted quite a lot of static builds of complicated thing, augmented Musl with various bits and scraps to make it more featureful. You gave a very nice intro for my talk, saying Nixpkgs could well be the future so check it out. Well, I hope that future can arive more widely soon :).
  - yjftsjthsd-h 5y ago
    https://github.com/richfelker/musl-cross-make https://github.com/richfelker/musl-cross-make ?
saagarjha 5y ago
Unfortunately most OSes ship their system call interface alongside the “userspace” parts of libc, so you can’t really pick and choose between the two :(
- ndesaulniers 5y ago
  Is this the case with Linux?
  - ameliaquining 5y ago
    No, Linux has a stable syscall interface (and is unusual in this respect). Consequently, fully static binaries are a reasonable thing to want on that platform (and a major motivation for this proposal is that building them is currently too difficult/annoying/unsupported).
    - saurik 5y ago
      So, the only reasons it is hard to statically link glibc--the NSS mechanisms for stuff like DNS and user authentication--are the same reasons why statically linking your libc on Linux doesn't make sense in the general case either: the mapping of names to identifiers on both the network and the machine are not part of the system call interface and are instead a property of the specific distribution you are working with; so, if you attempt to statically link that behavior and then run your binary on a fancy new Linux distribution, it won't be able to look up hostnames or usernames correctly. This is why for a while I had the only working busybox binaries for Android: I was the only person who went to the extra effort to NOT statically link it, but instead to port it to bionic.
- dundarious 5y ago
  As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. In fact, Linux offers nolibc.h as a nice header to get just syscalls and extremely basic functions like memcpy and strlen. The most up to date source at the moment is https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/tree/tools/include/nolibc/nolibc.h?h=dev https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linu... AFAIK (the linus master tree was missing some necessary fixes for x86_64 last I checked). On Windows, it is somewhat laborious and involves some debatable trade-offs, but you can avoid msvcrt/ucrt altogether but you must link with kernel32 for syscalls. I have a very minimal nomsvcrt.h that just defines types and externs for those syscalls defined in kernel32, but it's really incomplete -- it's easy to write your own based on win32 docs anyway. One additional thing you'll need though are all the compiler bits that are now missing, mostly dealing with floating point conversions. https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows https://hero.handmade.network/forums/code-discussion/t/94-gu... provides an excellent guide, but note the trade-offs made. I think the last thing you might want is a routine to turn GetCommandLineA()'s result into argc, *argv[], and if you can use LGPL, that's available in https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/exe_entry.c https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winec... I don't have a macOS system right now, but I'm willing to bet there's a similar scheme possible there. That covers a lot of systems. OpenBSD is the only system I know of that really enforces system calls to go through their libc, but I'm ignorant.
synergy20 5y ago
you can use either musl, or just golang/rust today. I wish one day c/c++ can cross-build just like what rust/golang does today.
- ndesaulniers 5y ago
  Andrew Kelley makes an interesting point in: https://www.youtube.com/watch?v=pq1XqP4-qOo https://www.youtube.com/watch?v=pq1XqP4-qOo about the PT_INTERP being hard-coded. That seems like a long ago assumption baked that binaries should only have one program interpreter per system. I don't know enough about configuring a system and the historical decisions around PT_INTERP, but I suspect Andrew is on to something.
  - account42 5y ago
    If you want to change the dynamic loader then you can't really interface with any system libraries anyway as they might rely on features in the system dynamic loader. At that point you have a completely separate userspace for your program and containers allow you to have that even with a fixed dynamic loader path.
    - ndesaulniers 5y ago
      Do you have a good reference on this aspect of containers that I could read that you'd recommend? (or anyone else)

yjftsjthsd-h 5y ago

You can do this today with musl, FWIW.

ndesaulniers 5y ago
You can, and I have done it. It's easy for hello world. But for larger projects it's more difficult. If anyone has even done a build of clang with this, I'd love to know!
- boogies 5y ago
  > If anyone has even done a build of clang with this, I'd love to know! Clang's in Alpine Linux's repo's, so I guess they have and this is how: https://git.alpinelinux.org/aports/tree/main/clang https://git.alpinelinux.org/aports/tree/main/clang
  - Aissen 5y ago
    They built clang against musl, just not statically.
- Ericson2314 5y ago
  I made https://github.com/NixOS/nixpkgs/pull/149523 https://github.com/NixOS/nixpkgs/pull/149523 to kick off nix-build -A pkgsStatic.llvmPackages.clang-unwrapped Which built all the other deps just fine, but failed buildling LLVM with CONFIGURE_LLVM_NATIVE. That seems easy enough to fix, as that's the regular part, though. No guarantee there wouldn't be other more serious issues lurking beneath, but we've attempted quite a lot of static builds of complicated thing, augmented Musl with various bits and scraps to make it more featureful. You gave a very nice intro for my talk, saying Nixpkgs could well be the future so check it out. Well, I hope that future can arive more widely soon :).
- yjftsjthsd-h 5y ago
  https://github.com/richfelker/musl-cross-make https://github.com/richfelker/musl-cross-make ?

saagarjha 5y ago

Unfortunately most OSes ship their system call interface alongside the “userspace” parts of libc, so you can’t really pick and choose between the two :(

ndesaulniers 5y ago
Is this the case with Linux?
- ameliaquining 5y ago
  No, Linux has a stable syscall interface (and is unusual in this respect). Consequently, fully static binaries are a reasonable thing to want on that platform (and a major motivation for this proposal is that building them is currently too difficult/annoying/unsupported).
  - saurik 5y ago
    So, the only reasons it is hard to statically link glibc--the NSS mechanisms for stuff like DNS and user authentication--are the same reasons why statically linking your libc on Linux doesn't make sense in the general case either: the mapping of names to identifiers on both the network and the machine are not part of the system call interface and are instead a property of the specific distribution you are working with; so, if you attempt to statically link that behavior and then run your binary on a fancy new Linux distribution, it won't be able to look up hostnames or usernames correctly. This is why for a while I had the only working busybox binaries for Android: I was the only person who went to the extra effort to NOT statically link it, but instead to port it to bionic.
dundarious 5y ago
As has been mentioned in other comments already, Linux has a stable ABI so you don't need a libc at all. In fact, Linux offers nolibc.h as a nice header to get just syscalls and extremely basic functions like memcpy and strlen. The most up to date source at the moment is https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/tree/tools/include/nolibc/nolibc.h?h=dev https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linu... AFAIK (the linus master tree was missing some necessary fixes for x86_64 last I checked). On Windows, it is somewhat laborious and involves some debatable trade-offs, but you can avoid msvcrt/ucrt altogether but you must link with kernel32 for syscalls. I have a very minimal nomsvcrt.h that just defines types and externs for those syscalls defined in kernel32, but it's really incomplete -- it's easy to write your own based on win32 docs anyway. One additional thing you'll need though are all the compiler bits that are now missing, mostly dealing with floating point conversions. https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows https://hero.handmade.network/forums/code-discussion/t/94-gu... provides an excellent guide, but note the trade-offs made. I think the last thing you might want is a routine to turn GetCommandLineA()'s result into argc, *argv[], and if you can use LGPL, that's available in https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/exe_entry.c https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winec... I don't have a macOS system right now, but I'm willing to bet there's a similar scheme possible there. That covers a lot of systems. OpenBSD is the only system I know of that really enforces system calls to go through their libc, but I'm ignorant.

synergy20 5y ago

you can use either musl, or just golang/rust today. I wish one day c/c++ can cross-build just like what rust/golang does today.

ndesaulniers 5y ago
Andrew Kelley makes an interesting point in: https://www.youtube.com/watch?v=pq1XqP4-qOo https://www.youtube.com/watch?v=pq1XqP4-qOo about the PT_INTERP being hard-coded. That seems like a long ago assumption baked that binaries should only have one program interpreter per system. I don't know enough about configuring a system and the historical decisions around PT_INTERP, but I suspect Andrew is on to something.
- account42 5y ago
  If you want to change the dynamic loader then you can't really interface with any system libraries anyway as they might rely on features in the system dynamic loader. At that point you have a completely separate userspace for your program and containers allow you to have that even with a fixed dynamic loader path.
  - ndesaulniers 5y ago
    Do you have a good reference on this aspect of containers that I could read that you'd recommend? (or anyone else)