>From my recollection talking to the OpenBSD hackers that added them, these syscalls were designed to solve 1.5 problems.
1: Primarly, sandboxes can interfere with getting the right files in the right place. 1.5; If a program is compromised, shellcode can dup over the random fd, allowing an attacker to replace a source of randomness with a known stream of values, which could lead to secretly broken cryptography. For problem 1, I don't think we have an issue getting the right files into sandboxes. We have to get our namespaces right, because so many of important resources are named, rather than accessed by ioctl or syscall. And because we have to get everything else right, we also have to get access to bintime and random right. Note that for similar interaction with sandbox reasons, OpenBSD is adding special hooks to the kernel for yp(8) https://man.openbsd.org/yp. If our goal is to have go work in incomplete sandbox environments, we have a lot of work cut out for us; I don't think it's a worthwhile goal. For problem 2: If a program is compromised, there are so many other more interesting things it can do. However, if that's your concern, we should look into more general security hardening. If the goal is performance, any syscall is much of a muchness, and keeping things in userspace is the way to go. As far as this: > Or the kernel would have to share a memory page with the parameters with > the user process, and then that layout becomes part of the kernel interface. We already have that with the TOS. It even has a low res clock in there. The last thing mentioned was accidentally opening things over standard FDs. This strikes me as a very odd concern. If a system is going to accidentally clobber a standard fd, it's going to be one of the calls churning through file descriptors, and not one of these nearly static calls. So, while I undersatnd the desire for these calls in other contexts, the reasons for adding them don't seem applicable. Quoth Russ Cox <r...@swtch.com>: > Thanks for the feedback so far. Correcting cinap's email address on this > reply. > > I don't believe having a #c/magicfds file is a net win. Certainly if it is > writable / configurable, then much of the benefit is lost. The benefit is > not having to do set up like opening files and holding an fd open at > process startup, even temporarily. Like rfork(2) or sbrk(2) or other system > calls, I argue that these specific operations (read time and read entropy) > have become so fundamental to modern programs that they should be available > without the ceremony and conceptual overhead of managing long-term fds. A > readable one might be useful as documentation, but if it's a hard-coded set > then the kread(2) man page should suffice. > > As for user-space time access, it is true that on 386 and amd64 we could > use RDTSC and saved clock parameters. We've actually moved away from that > on basically every operating system at this point, because the parameters > do change, and we need to know when to update them. Or the kernel would > have to share a memory page with the parameters with the user process, and > then that layout becomes part of the kernel interface. Of course we could > add shared code that the kernel leaves to be called as well. All of that > seems too complex and bespoke. (On Linux that's exactly what happens, but I > repeat myself.) And I don't know what we'd do instead on arm. > > The Blue Gene system call batching also seems a bit much to me, especially > since (1) we want to not have to keep the fd open, (2) we don't want to > hard-code the target pointer for the read, and (3) ideally we don't want to > go through a per-process setup dance that includes opening files each time > a process is created. I wouldn't mind the per-process setup if (1) and (2) > were not problems as well. > > Best, > Russ ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T59810df4fe34a033-M2157559319a4d6f3dfb00ca0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
