Greg Kurtzer's Ginux is now a userspace kernel
github.com
github.com
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...
soon after that, the laid-off hackers become the next builders :)
circles. revolutions. until its learned to see whats ahead, then it can be diverted to something new
Option A is the best practices status quo for a lot of people. "Don't waste time and money reinventing the wheel", "Given enough eyes, all bugs are shallow", etc...
But Option Z is becoming cheap and fast, and given all the eyes, there still seem to be a lot of bugs in Option A.
Maybe it's better to tolerate a few bugs so long as it's not the same bug on everyone's computer.
Maybe you have fewer bugs if you aren't supporting 50 years of backwards compatibility.
Maybe the economics and risks change for the hacker when he can't find bugs offline.
Maybe we should appreciate people researching how to vibe code containers and kernels.
So it can very well be worst of bith worlds, worse security on actually homogeneous systems.
The dude who says, "Give me a microkernel, use QNX request/receive/respond for syscalls, it only runs WASM blobs, device drivers are isolated user mode processes, it only supports HTTPS on one network interface, and the file system is readonly ExFAT" will probably get something different.
I hate low value LLM prose (slop) too, but if you ask it to write like Herman Melville, you'll get few "it's not this, it's that".
Maybe you do still get the same kinds of errors when you ask for VMS, 64 bit memory safe DOS, or a Unikernel. I dunno, but it seems like something that could be improved when it's identified.
Ok, you have me intrigued. FreeDOS-64!
If the host's network driver is hacked, all userland is stolen too.
Someone more qualified than me can speak to isolating device drivers. I do know that one of the virtues of microkernels was supposed to be that you can run drivers unprivileged.
Sarcasm? Definitely not true, by several orders of magnitude. Have you seen how many built-in functions PHP has?
Just to clarify: I didn't mean the effort to find and fix a vulnerability in PHP (although that is also difficult). I meant the effort to reformat your system, investigate what else was compromised, and recover from backups after you get hacked through an exploit in PHP.
You probably don't use every last function, and you might be underestimating what became possible this year. You could have a model search for the features you use. You could have it loop until your existing code passes with the substitute. You could have it rewrite your code to use fewer features while still passing your existing tests.
I'm not saying you have to do this, but I think we should question which of our old approaches are based on old constraints.
(Better yet, just regular code it!)
Also this is like the worst case where the bug is in one monolithic piece of sw. Something like the alpine ssh bug is more relevant, you can plainly see not all systems are effected.
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.)
Yes, I've tried using it before.
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?
Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.
But I’m not sure if that is really possible.
The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.
OTOH, running a messy environment with rollback support is much easier with a VM than a container.
Containers are fun for packing messy executables into their own environment and run them now and then, though.
Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.
Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.
The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.
.... Right. Exactly. Everything has some vulnerabilities, but if an attacker has to use a relatively rare VM escape, that's a huge win.
Never change, HN, never change :D
> That research phase is complete.
So not sure what part of it now constitutes "research and exploration".
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
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.
This is incorrect. If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic.
Is there any new language close to rust which can help being verified using formal methods or would some other language be more suitable for this job?
Maybe using verus + rust, it seems that atmosphere[0] is an interesting project in this space
But I'm not going to try to guess what you wanted to say and then discuss that, because I'll probably guess wrong.
Instead of complaining when people point out that what you said was false, you should thank them for taking the time to correct you and take the opportunity to learn from it. Then, be more careful about what you say next time, so that you say things that are true instead of false.
So you should carefully read and consider the conversation before you write, least you come across as arrogant and foolish.
Whether this works or not—or, more defensibly, how great the risk is—depends a great deal on the details.
I'm not really interested in how I appear to you, so I recommend you don't waste your time telling me about it.
But I don't think this is a technical conversation anymore, you have some other problems to address and it is best you do that.
> 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.
I’m still trying to figure out exactly what it is.
You could probably work around this partially by having contracts with people, but these in turn also depend on the AI slop then, so the problem is just shifted.
The slop problem is also a challenge to overcome. The project barely existed and has already pivoted in a completely new direction. Who knows when this direction bores the author and we get yet another pivot. Or the author loses interest and we end up with a dead pile of abandoned code like so many other LLM generated projects.
The previous state of the project could've made for an interesting VM runtime (safety of Rust without the issues that come with the lack of ported drivers). For this new direction, I don't think there's a similar sort of demand.
Stating that nobody will take it seriously is probably an exaggeration, but I consider these projects to be toys for the author to play with, I don't see why you would take more interest than going "huh, neat I guess".
A project picked up casually, for a short time, is likely to be dropped casually, in a short time.
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.