zlacker

Sounds like Android is making a microkernel out of Linux.

>>speed_+(OP)
There are some huge drivers from companies like Broadcom and Qualcomm. There's still a massive amount of kernel driver code along with the massive amount of core kernel code. Android is the main driving force behind the push for Rust for Linux kernel drivers because Google wants all these SoC and device drivers to start being written in Rust for security reasons but also for stability too. Driver memory corruption bugs are a huge source of both security and stability issues. A majority of new code in Android releases since Android 13 has been in memory safe languages. The Linux kernel is increasingly the elephant in the room with the monolithic kernel driver (zero isolation / sandboxing within the kernel) combined with memory unsafety. It's largely the opposite of Android's extensive work to improve security in userspace. They've worked hard on getting exploit mitigations into the kernel but those tend to be much weaker than they are in a lot of userspace (browser renderer processes have similar issues).

>>speed_+(OP)
For entire classes of applications, you can treat Linux as a black box. Things like syscalls, /proc & /sys, are all incredibly stable. So that's what Go does with its syscall package; it completely sidesteps libc, ld.so, and whenever it can, it just produces static builds - at least on Linux.

They tried to get away with it on OpenBSD, macOS, etc and got their hand chewed off.

>>rollca+lc
There are a few reasons I avoid Go, and their syscall pacakge is on the list. It breaks a bunch of tooling that requires LD_PRELOAD or static linker interposition. (One example: Interposing on the clock to test timeout logic.)

I wish they had an option that just used libc. Maybe, someday someone will add a target architecture/port that just uses posix. I’d prefer that in Linux too.

>>hedora+kU
Intercept at the syscall level instead with seccomp. Like I'm doing here:

https://github.com/lukasstraub2/intercept-anything

Go is hardly the only thing where LD_PRELOAD doesn't work.

>>hedora+kU
That's not Go-specific, it's just how static linking works. As nolist_policy advised, it's more useful and precise to intercept programs at the syscall (rather than library call) boundaries. Programs are free to do all sorts of insane stuff, there was e.g. a Scheme interpreter that kept growing the stack until it caught SIGSEGV, at which point it'd run a compacting GC and reset the stack pointer. ¯\_(ツ)_/¯

Regarding LD_PRELOAD, I highly doubt that this is required by POSIX. macOS (which is a certified UNIX) uses DYLD_INSERT_LIBRARIES instead. OpenBSD (which is known for their pedantic documentation) uses LD_LIBRARY_PATH, doesn't mention any standards, and refers the reader to SunOS 4.0. If this is somehow standardised, I'd love to read the actual document.