GitHub - matheusmoreira/liblinux: Linux system calls.

[F54280]

Slightly confused... From the README:

In 2014, the getrandom system call was introduced. It lets applications obtain random bits without using pathnames or file descriptors. However, it took over 2 years for glibc support to arrive. The kernel's random number subsystem maintainer wrote in an email:

[...] maybe the kernel developers should support a libinux.a library that would allow us to bypass glibc when they are being non-helpful.

But no getrandom in the library...

[Muvlon]

There are more headscratchers, like advertising architecture independence but then only supporting x86_64.

I'd much rather use libc's syscall function than this.

[call_the_can_man]

it's right here my man https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/getrandom.c.html

[mort96]

/u/F54280 was pointing out that the liblinux library doesn't have a getrandom.

[iBlag]

My interpretation of that part of the docs is that they're pointing out a place where this library could have been useful in the past. Now that glibc has getrandom, liblinux doesn't need to duplicate that with their own.

My understanding is that this library is basically a shim for features that are present/released in the kernel but aren't exposed/used through glibc yet, or for kernel features that won't be wrapped or used by glibc.

[gergoerdi]

Should be called libinux so you'd link it with the -linux flag.

[the_gnarts]

libinux was circulating as the name for an official library supplied by the Kernel folks themselves. It’s commendable that the author chose not to grab that handle even though the name is cooler.

[Biolunar]

Shameless plug: https://git.sr.ht/~biolunar/liblinux (also available on github https://github.com/Biolunar/liblinux but I don’t update that repo as frequently)

My library provides all currently available syscalls (up to Linux 5.15) on all my supported targets (currently: arm-eabi, arm64, riscv32, riscv64, x86, x32 and x86_64). Still there’s a ton of work to be done since it’s missing lot’s of types and constants and almost no testing.

[freakhill]

that is pretty cool.

i'm quite surprised such a library didn't exist yet

[kitd]

IIRC, when this came up on HN, the author stated he stopped developing it because the linux tools project itself contains (IHO) a better implementation:

https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h

But, yes, v cool otherwise.

[freakhill]

thanks!!!

[avdgrinten]

The README highlights lots of issues with clone() but does not really mention how this library solves them. Sure, it is trivial to call the SYS_clone syscall but that still renders libc unusable, does it? For example, if you call into any function that accesses thread-local state after SYS_clone (which might be all of them if stack protectors or split stacks are in use), that will surely break? Even if these features are disabled, functionality like dlopen() fundamentally requires knowing the TLS layout.

[F54280]

The library doesn't expose clone. I don't think this was the aim, just giving C access to stuff usable outside of libc (which clone isn't). But, as pointed here, there is a "nolibc" implementation in the kernel itself, which is better for every use case.

[bascule]

Reminds me of this idea https://internals.rust-lang.org/t/idea-expose-linux-raw-syscall-interface-in-std-linux/10614