3 ms·

I know that DragonflyBSD was born on the idea of implementing syscalls as a messages, while retaining the structure of a monolithic kernel (FreeBSD 4), but I do

I know that DragonflyBSD was born on the idea of implementing syscalls as a messages, while retaining the structure of a monolithic kernel (FreeBSD 4), but I don't know if the messages are kept in userland or there's still a context switch involved. The annoying part of having a relatively large piece of shared data between userland and kernel is that the kernel needs a way to ensure that this data hasn't been tampered with "illegally". I wonder how this is handled with io_uring.

atq2119 5y ago
Is this really fundamentally different to existing syscalls? They already have to guard against the possibility that another thread does funny business with the memory accesses by the syscall. You add ring buffer control structures, sure, but apart from that it seems largely the same problem?
- fstrthnscnd 5y ago
  I don't know much about kernel security dev, let alone plain kernel dev, so take what I said and about to say with a (big) grain of salt. Indeed, it seems there's a similar issue with traditional syscalls. I suppose that a larger attack surface means more potential vulnerabilities. The whole buffer must be considered "unsafe" by the kernel. I don't know how that structure is allocated, if it can be relocated to some other existing area to trick the kernel into doing IO there or something else. I really don't have a clear picture of what could be done, so it might just be my paranoid sense tingling. I definitely should be more trustful wrt what's done by the kernel devs, they know their craft.
- rektide 5y ago
  > Is this really fundamentally different to existing syscalls? Originally & perhaps still DragonflyBSD was attempting to become a Single-System-Image OS, was supposed to allow multiple boxes to work together in a way that looked like a single computer. I could definitely see making syscalls be more like messages as being a useful starting abstraction for this scenario.
lathiat 5y ago
Sounds like the “file sealing” API combined with memfd handles that: https://lwn.net/Articles/593918/ https://lwn.net/Articles/593918/

atq2119 5y ago

Is this really fundamentally different to existing syscalls? They already have to guard against the possibility that another thread does funny business with the memory accesses by the syscall. You add ring buffer control structures, sure, but apart from that it seems largely the same problem?

fstrthnscnd 5y ago
I don't know much about kernel security dev, let alone plain kernel dev, so take what I said and about to say with a (big) grain of salt. Indeed, it seems there's a similar issue with traditional syscalls. I suppose that a larger attack surface means more potential vulnerabilities. The whole buffer must be considered "unsafe" by the kernel. I don't know how that structure is allocated, if it can be relocated to some other existing area to trick the kernel into doing IO there or something else. I really don't have a clear picture of what could be done, so it might just be my paranoid sense tingling. I definitely should be more trustful wrt what's done by the kernel devs, they know their craft.
rektide 5y ago
> Is this really fundamentally different to existing syscalls? Originally & perhaps still DragonflyBSD was attempting to become a Single-System-Image OS, was supposed to allow multiple boxes to work together in a way that looked like a single computer. I could definitely see making syscalls be more like messages as being a useful starting abstraction for this scenario.

lathiat 5y ago

Sounds like the “file sealing” API combined with memfd handles that: https://lwn.net/Articles/593918/ https://lwn.net/Articles/593918/