The question I always have when I see these userspace kernels is, Linux in Userspace exists. You can boot Linux with a root in userspace already. Why write a new kernel from scratch instead of fixing/improving usermode Linux instead, which has the benefit of providing the entire Linux API already?
Option A) Everyone shares one OS (container, sandbox, kernel, firewall, whatever). It gets a lot of eyes on it to find bugs. Hacker fuzzes it with a lot of tokens offline. He finds one exploitable vulnerability and he owns everyone.
Option Z) Everyone vibe codes their own custom OS. Each implements and exposes only what they want. Hacker has to beat up on it online to find vulnerabilities. He finds one and he only owns that one machine.
There's probably some middle ground between A and Z, but monocultures are fragile. All eggs in one basket, potato famines, banana fungus, etc...
Not OP but security and ressource usage are often the main motivators.
For security, GVisor is probably the most widely used userspace-kernel. A userspace kernel may also boot faster and use less resources as it can offload a lot of work to the host (FS drivers etc.)
This is really awesome and the next rabbit hole I want to check out. I'm on the defensive making software for me running AIs in the most secure way possible, and one main lack was the ability to fully guard against kernel attacks should a jailbreak happen. Its another layer I can add for defense in depth, thanks!
The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.
This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.
If it has to go through another layer , hopefully without ring0 privs, which more than likely may filter out a number of exploit vectors, how is this the wrong approach ?
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
So how exactly can you control multiple isolated address spaces for the leaf user processes and how do you handle syscalls? Does the host kernel have facilities for normal user processes to do so?
> The current implementation includes a security-focused x86-64 interpreter and a balanced native ptrace backend;
ptrace allows you to have the kernel redirect syscalls back to userspace, mostly for debugging purposes. "balanced" here refers to speed, but the overhead is still quite high.
More seriously, it is a great use of indirection insofar as replacing the full Linux kernel is a gargantuan task. A userspace kernel per task or task group.. makes a lot of sense. I'd be interested to know how it captures syscalls - eBPF? It wasn't obvious from a skim of the readme.
This kind of give-me-this-interface work seems pretty perfect for LLMs, too.
A big concern for me is this: would an AI generated kernel be built with a backdoor or hidden vulnerability by the AI engine generating the code?
The question I always have when I see these userspace kernels is, Linux in Userspace exists. You can boot Linux with a root in userspace already. Why write a new kernel from scratch instead of fixing/improving usermode Linux instead, which has the benefit of providing the entire Linux API already?
Option A) Everyone shares one OS (container, sandbox, kernel, firewall, whatever). It gets a lot of eyes on it to find bugs. Hacker fuzzes it with a lot of tokens offline. He finds one exploitable vulnerability and he owns everyone.
Option Z) Everyone vibe codes their own custom OS. Each implements and exposes only what they want. Hacker has to beat up on it online to find vulnerabilities. He finds one and he only owns that one machine.
There's probably some middle ground between A and Z, but monocultures are fragile. All eggs in one basket, potato famines, banana fungus, etc...
Not OP but security and ressource usage are often the main motivators.
For security, GVisor is probably the most widely used userspace-kernel. A userspace kernel may also boot faster and use less resources as it can offload a lot of work to the host (FS drivers etc.)
How is Ginux different from User mode Linux?
https://en.wikipedia.org/wiki/User-mode_Linux
It seems to be more like gVisor than UML, providing a restricted kernel interface as opposed to the full kernel.
It is AI slop.
This is really awesome and the next rabbit hole I want to check out. I'm on the defensive making software for me running AIs in the most secure way possible, and one main lack was the ability to fully guard against kernel attacks should a jailbreak happen. Its another layer I can add for defense in depth, thanks!
https://github.com/RALaBarge/enclave
This is kind of the wrong approach when linux namespaces exist and rootless namespaces are approach full spectrum.
The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.
This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.
I’m still fascinated by the approach, though. It seems to me that it sits somewhere between cgroups and virtual machines.
I do wonder what problem it solves, as I don’t think that it provides the same security guarantees that micro-VMs like firecracker do?
Rootless namespaces are getting better, but they don't eliminate the host kernel attack surface
You can combine hypervisors, user space kernels and linux namespaces all into one solution. The attacker will have to escape all of them.
Isn't this also adding a capability sort of like OpenBSD's pledge?
If it has to go through another layer , hopefully without ring0 privs, which more than likely may filter out a number of exploit vectors, how is this the wrong approach ?
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
> Telling someone's research and exploration is wrong...
Never change, HN, never change :D
So how exactly can you control multiple isolated address spaces for the leaf user processes and how do you handle syscalls? Does the host kernel have facilities for normal user processes to do so?
From the README
> The current implementation includes a security-focused x86-64 interpreter and a balanced native ptrace backend;
ptrace allows you to have the kernel redirect syscalls back to userspace, mostly for debugging purposes. "balanced" here refers to speed, but the overhead is still quite high.
Post from yesterday: https://news.ycombinator.com/item?id=50424147
Talk about pivoting. I guess that's what you call lean and agile.
probably you get more isolation with jslinux
My immediate thought was this: https://en.wikipedia.org/wiki/User-mode_Linux
More seriously, it is a great use of indirection insofar as replacing the full Linux kernel is a gargantuan task. A userspace kernel per task or task group.. makes a lot of sense. I'd be interested to know how it captures syscalls - eBPF? It wasn't obvious from a skim of the readme.
This kind of give-me-this-interface work seems pretty perfect for LLMs, too.
The issue with this kind of thing is nobody will take it seriously.
Why? Because a user space kernel is a bad idea? Or because of the AI use when writing it?
I’m still trying to figure out exactly what it is.
Nobody will take him seriously.
Guys - AI slop is winning the war. Soon the Top 500 Supercomputers will run AI-Ginux rather than Linus-Linux.
When something has to be secure and battle-tested, this won’t happen. It can be written with the help AI, but it needs many humans to verify.
Don't worry, Linus-Linux already stands on the AI slop side.