4 ms·
I've come to think that the whole distinction "kernel vs userland" is inflexible. There was a thread here on HN a few days ago, and it showed some clear defici
by jstimpfle 10y ago
I've come to think that the whole distinction "kernel vs userland" is inflexible.
There was a thread here on HN a few days ago, and it showed some clear deficits of conventional OS, for example in processes. Speaking of lack of composability of clients and linked-in libraries, speaking of IPC and uncontrolled implicit environment inheritance (Docker... :<), speaking of the ad-hoc security model (Unix permissions, setuid hacks, and more recently extended attributes).
There's just a single trust boundary in Unix. What if the system was instead just a graph of interacting entities, each managing control over some resource? The "userland process" would just be another entity that is in control of another (more ephemeral) resource. We wouldn't even separate address spaces!
Security by careful propagation through fine-grained trust boundaries (instead of globally accessible resource managers that have a hard time deciding whether a requesting entity should be authorized). Think svn vs git.
And my understanding is that that's much of what Lisp Machines were about...
- morb 10y agoCould you please link to the mentioned thread?
- jstimpfle 10y agohttps://news.ycombinator.com/item?id=13621623 https://news.ycombinator.com/item?id=13621623 If you search for my name there, you will find at least discussions about file modes and also why I claim that processes are a failed abstraction (it was really another user who pointed that out).
- nwmcsween 10y agoDefine 'separate address spaces', you have linear address space (virtual) and kernel/user 'address spaces' which are address spaces but not in the way linear address spaces are. It would be easier to simply move almost everything not needed by the kernel into 'userspace' and have some sort of capability system to enforce access rights.
- jstimpfle 10y agoThere is a missing word; I meant to say "we wouldn't even need separate address spaces" ("separate" was meant as an adjective, not as a verb). And by that I meant that we would need no hardware support for separate address spaces. The kernel and all processes would share a single address space. We could look at memory as just another resource, and readable or writeable chunks of memory ("buffers") would be only accessible through authorized "memory arbitrator" entities. Of course some mechanism is required to prevent programs from making up buffers on their own; this can be done in hardware of course, but alternatively also by software mechanism, e.g. enforcing a higher-level programming language like Lisp. So one could even say that each such buffer was their own address space; however I'm convinced the approach is much simpler and less arbitrary (no coupling process<->address space). "Virtual address spaces" are a required abstraction, just as filesystems need to provide the illusion of contiguous available storage for files. This could of course be done in software, just as filesystems do it in software. However it would be a lot slower since we don't batch memory accesses like we batch file accesses.
- krylon 10y agoIIRC, Microsoft tried to build something along those lines with the Singularity research operating system - it did not use virtual memory to isolate processes from each other, but it strongly restricted how processes could exchange data, thus getting pretty much the same isolation level conventional operating systems get by using virtual memory. I even think the source code to Singularity has been released under an open source-ish license, if you want to look into it.
- jstimpfle 10y agoThanks, I will look it up!
- justincormack 10y agoThere have been a bunch of single address space (64 bit!) OS projects http://wiki.c2.com/?SingleAddressSpaceOperatingSystem http://wiki.c2.com/?SingleAddressSpaceOperatingSystem