3 ms·
Is this really fundamentally different to existing syscalls? They already have to guard against the possibility that another thread does funny business with the
by 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 agoI 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.