lmao that copy.fail was in linux/crypto/
Post
Replies:
15
Boosts:
8
so, it's worth reconsidering whether blame needs to be a bad word. it can be reframed as responsibility. in addition to making it harder for contributors to make mistakes, we also have to consider how to limit the ability of contributors to harm users. this encourages more forms of direct democracy, instead of hyperspecialization and hierarchy as seen in the linux codebase
ideally, a microkernel should also help to reduce the scale of the project to make it possible to be familiar enough with most of the code to review others' work
it's not a magic bullet but rather a bundle of strategies to enable deep trust over the code that runs in ring 0. an additional result is in lowering the barrier to contributions. i suspect receptivity to forks would be a good thing, but also if the project needs to be forked, that could be a sign it's not microkerneling hard enough
grapheneos is much more ambitious and it remains secure partially by limiting hardware support, which further enables it to reduce the amount of trusted code. it also integrates cryptography into the boot process and in other ways generally understands that the operating system's purpose is to act as the trusted computing base.
linux acts like the os is supposed to have a constant stream of sick new features for really specific situations (splice and io_uring in particular), which constantly exposes it to vulns. if you need to run in kernel space to access hardware, you're going to have a conflict between feature support and security eventually. so i think interfaces which enable deep integration with hardware without needing to pull in code to the kernel source tree that runs in ring 0 is a research goal for the future
this also has a lot of practical utility because it sucks that you essentially can't ship a kernel module to users like other types of code. FUSE is an example of how to expose safe interfaces (although FUSE also necessarily doesn't interface with hardware. need to learn.....so much more about the motherboard to figure this out)
this was inspired by https://www.askbaize.com/blog/linux-compromises-broken-embargoes-and-the-shrinking-patch-window, which i didn't know at all would explicitly mention splice and io_uring (both places intentionally created to share memory between the kernel and userspace). this is the kind of thing imo that really can't be done as a one-off and indicates that the kernel really shouldn't be managing i/o in the first place (gasp!)
the reason the kernel has to manage i/o is because the kernel is the only thing that can connect to the hardware, which is where i/o happens. the reason this pisses me off is because it also imposes the kernel's idea of how i/o scheduling should work, which application programmers (build tools, package managers) constantly have to work against
it's a well-known meme that databases have to tell the kernel to stop fucking with the pages they allocate and let the db software manage things directly, because the db works differently than the kind of software that the page cache was made for. this isn't understood as the serious indictment of many os-based abstractions which to my understanding date back before unix
i have wanted less monolithic i/o APIs for years because they kept getting in the way of perf. in particular, most programming language async APIs are extremely detrimental to local i/o and are optimized for network traffic in a variety of ways. the kernel imposing very limited mechanisms for i/o scheduling makes it quite difficult to get "close to the metal", or on the other hand, to get "close to the user" by representing a precise set of application-level constraints
it's obviously a huge task to produce an interface that enables high-performance i/o without sharing the same memory space or even the same build system. it can be thought of as the difference between an existential vs universal quantifier. but the result will mean highly specialized application domains don't have to work around assumptions made for other use cases. and highly-secure systems won't incur tradeoffs made for other systems with less stringent requirements
with the establishment of standards (sel4 being the closest to what i want to see), this shouldn't then mean code becomes less portable. in fact, i think it should increase portability as OS interfaces become less of a product of the monolithic OS version, but rather a construction of userspace code that can be constructed independently of the kernel
the violence of a monolithic kernel is in needing to support every use case. with linux, this has led to compounding degrees of driver support, because the only way to support your hardware at all is to get it into the kernel. like the GPL(v2), it was an effective approach to coerce corporations to contribute code. but it achieved this coercion via monopoly. and eventually, corporate use cases became preferenced. this is not a problem for linus, who gets free labor and state-of-the-art research into his little project. but it becomes problematic for those who are at odds with corporate or government initiatives
militaries globally contribute to much legitimate work in cybersecurity. even the legitimate work still enables the militaries of the world to dictate which architectures of security survive and remain extant. this is in fact the story of the so-called internet, which at every point makes technical decisions that enable surveillance and censorship, without accountability.
the internet is in fact not a reliable network—have you noticed this? a reliable network is not one which makes routing invisible, and demands you resend data it dropped. a reliable network makes routing transparent and user-defined (i am indeed describing source routing here), so that failures can be immediately triangulated, and the user can route around censorship imposed by the network
