Hacker News Reader

Comment by gxt | Hacker News Reader

Please please please, all new OSes need to batch all syscalls by default, and all security contexts need to take into account all of program-origin, program, and user. Also please limit whatever your equivalent of root to deny and delete. Thanks

View on HN

Absolutely batch and use asynchronous completion. All modern systems (NFSv4, GPUs, NVMe, etc) uses a variation of the theme. However, one should also work on lowering the context switch cost.

Another notion that I find interesting is one-address space. You still get per process protection, but address space is global. Supporting virtual memory is extremely expensive (we are paying the price today with hardware table walkers, multi-level caching of translations, various flushing on context switches). It is much cheaper if we only have to implement permissions (there are many options here) and it can make zero-copy process communication much cheaper.

Also, if you are giving up on paging, we can move beyond the 4096 byte page which we got with the 1962 Atlas (it had the equivalent of 96 KiB total memory; if pages had kept that ratio we would be using ~ 8 GiB pages today).

> Another notion that I find interesting is one-address space. ... Supporting virtual memory is extremely expensive

Would it be possible to make linux work with one address space? It seems like that should be a reasonably easy thing to do given how many different hardware platforms linux runs on. And it'd be interesting to know how much performance uplift you get from not flushing as much during context switches.

Or are there more complex interactions with different parts of the kernel that I'm missing?

I didn’t assume Linux binaries would work and I don’t see how to make that work, but general application that doesn’t depend on mmap or the Linux ABI can work.

> Would it be possible to make linux work with one address space?

Not without major changes to programs' ABI. On Linux with an address space per process, programs depend on having their private resources on fixed addresses.

The upcoming/vaporware The Mill CPU offers only a single address space, and emulates fixed addresses by aliasing a fixed part of each process' address space to somewhere else — in hardware.

In software, the ABI would have to pass a pointer to each callee's context when calling them. This is e.g. what you did in AmigaOS when you called a library function. But not all functions can be this way. You don't want all "function pointers" to be fat: function and context. For those to work, dereferenced functions would need to either belong to the program binary only, be "pure" (not access any global variables) or use a system service (on a fixed address..) to look up its context.

But the benefit of virtual memory is the contiguous memory (that those virtual indirections allows for) - ignoring virtual memory we risk falling down again to the "you need 600kb [of contiguous] conventional memory" issues of fragmented memory.

A MMU is complex, but allows simpler programs in the entire system overall.

I agree that abandoning virtual memory entirely brings back old problems, but there is a middle ground of a single virtual address space. This limits flushes to page table changes and makes it easier to move the MMU out of the CPU cores/caches. Page table size issues can be mitigated by larger or mixed size pages (and already is in x86_64/ARM)

> Also please limit whatever your equivalent of root to deny and delete.

So what creates/specifies user contexts, loads drivers, and installs kernel updates?

Hi, just out of interest since I am a novice in the area, I’d appreciate if you could elaborate on this comment.

1. Batching syscalls (and to me that implies copy-exactly-once IO, AKA Zero Copy in Linux/rust) means you can better manage the cost of performing syscalls and IO in high throughput and low latency use case. Eg if you expect a bunch of network packets, the physical card, driver, network stack should split packet headers and data in distinct buffers, each contiguous, in memory. With batched syscalls, you could also instruct the kernel to memmap a file in memory, and finally combine both syscalls into a single copy from Io to Io giving the memmap buffer as the output buffer to the network stack. I don't know how this could be done today, even with iouring, but I expect this would significantly outperform existing solutions as there would be a single copy operation instead of at least 3.

2. Per origin, per program, and per identity security context I think is required to deal away with the current prerequisite of all web browsers that the underlying system be uncompromised. Basically a world where every js bundle gets executed with it's own user as its own process and having to explicitly request access to your data.

3. Combined with the above to limit the risk of compromised root accounts, if they are limited to causing DOS and data loss it's much less dangerous than a world where your entire life can be usurped by assholes with a 0day. This implies major changes in driver architectures of OS/kernels but I think it's entirely unreasonable not to make these changes. The world has changed since the 90s.

My phone has this thing where apps ask permission for my contacts. I would prefer something that worked more like, App says to OS, please let the user select a contact and then give me an opaque identifier that I can use to send data to the contact. This way the desired functionality is there, but the app never gets the contact list.

This is what Flatpak tries to do; provide "portal" APIs, that only provide a small slice of your system (one file, one folder, one screen to share), instead of allowing rampart access to the entire system and hoping that the program does nothing wrong.

I also wish more Flatpak applications actually used those sandboxing options.

> batch all syscalls by default

Switching from user mode to kernel mode and back (a “context switch”) is expensive. Traditionally, OSes did that on every system call. You can go faster if you have some mechanism for sending more than one system call in a single context switch.

> security context

Basically, what is a program allowed to do? Traditionally, Unixy (nowadays, Linux and friends) limit this based on just the current user, assuming that the user trusts every program they run. But nowadays you often don’t trust every program you run, and want it to be in its own limited sandbox.

> limit […] root

Most OSes have a super user that can do anything (pid 0 on Unixy things; Windows is more complex but still has them). They’re saying to not have that, instead make the super user only capable of stopping problematic things, not creating new things.

This is the one I’m more ambivalent on. At some point something has to set up the whole system, and the thing that kicks that off is going to look pretty superuser-like to me.

Reply on news.ycombinator.com