Great timing! I was trying out Haiku on a whim last night (in VirtualBox).
Such a different experience to the last non-mainstream OS I tried (Plan 9). Not a bad one, though. Blisteringly responsive, visually pretty, and containing many of my old friends (Emacs, bash, git).
For what it’s worth: FreeBSD made getentropy a system call rather than a read of the device to better support Capsicum. Without this, you needed to open the random device before entering capability mode.
Yes, that’s what’s happening here: Haiku has a “generic syscall” mechanism which functions something like “ioctl without a file descriptor”. The kernel and drivers can register themselves to be invoked through this system. You can see the commit that implemented this.
Ah, I thought you were just asking if “getentropy” worked without using file-descriptor, to which the answer is “yes.” We didn’t implement it this way to support Capsicum or anything, but rather so that getentropy still works properly when a process is close to its limit of FDs, and also for efficiency so it doesn’t need an open/close on every invocation.
Ah. The perf wasn’t an issue on FreeBSD because a process rarely calls it (it seeds a PRNG in libc that periodically gets more entropy, if you’re calling it on a hot path then you’re doing something wrong, especially on modern x86 where you really want to feed RDRAND into your userspace PRNG and just use getentropy once to protect against supply chain attacks on the hardware RNG [FreeBSD doesn’t do this yet]). I don’t think the old code did an open and close every invocation, just an open on first use.
Running out of file descriptors might be an issue, but those limits have been high enough that non-malicious code doesn’t hit them and if you’re one below them then you have so many open that you’re probably going to see failures from other things soon. Does Haiku have low limits here? It was a problem on OS X for the first couple of releases because the default values hadn’t changed since OPENSTEP 4, I had a script that set the sysctl values to a couple of orders of magnitude higher than the default to prevent things dying, but after 10.4 Apple made the defaults sensible.
It was essential for Capsicum because you lose access to the global namespace once you enter capability mode and so can’t open the device mode. You’d need libc to open the device before you called cap_enter and that might have surprising effects (in particular, code often does closefrom just after for some defence in depth against things being accidentally opened concurrently). I believe Linux did it for similar reasons (seccomp-bpf policies wanting to disallow open and not being able to special case a particular path because BPF can’t see into string arguments).
I imagine the perf wouldn’t have been an issue indeed, but we wanted to do things correctly nonetheless.
I don’t think our limits are especially low. We’ve raised them now and again when big applications come along, but it’s been a while since we’ve needed to do that, I think.
Great timing! I was trying out Haiku on a whim last night (in VirtualBox).
Such a different experience to the last non-mainstream OS I tried (Plan 9). Not a bad one, though. Blisteringly responsive, visually pretty, and containing many of my old friends (Emacs, bash, git).
For what it’s worth: FreeBSD made getentropy a system call rather than a read of the device to better support Capsicum. Without this, you needed to open the random device before entering capability mode.
I’d love to see Capsicum support in Haiku.
Yes, that’s what’s happening here: Haiku has a “generic syscall” mechanism which functions something like “ioctl without a file descriptor”. The kernel and drivers can register themselves to be invoked through this system. You can see the commit that implemented this.
Exciting. Is there a roadmap for capsicum support?
No, we don’t have any particular plans for that.
Sorry, I misunderstood the ‘that’s what’s happening here’. I’m now not sure what that meant in your previous post.
Ah, I thought you were just asking if “getentropy” worked without using file-descriptor, to which the answer is “yes.” We didn’t implement it this way to support Capsicum or anything, but rather so that
getentropystill works properly when a process is close to its limit of FDs, and also for efficiency so it doesn’t need anopen/closeon every invocation.Ah. The perf wasn’t an issue on FreeBSD because a process rarely calls it (it seeds a PRNG in libc that periodically gets more entropy, if you’re calling it on a hot path then you’re doing something wrong, especially on modern x86 where you really want to feed RDRAND into your userspace PRNG and just use getentropy once to protect against supply chain attacks on the hardware RNG [FreeBSD doesn’t do this yet]). I don’t think the old code did an open and close every invocation, just an open on first use.
Running out of file descriptors might be an issue, but those limits have been high enough that non-malicious code doesn’t hit them and if you’re one below them then you have so many open that you’re probably going to see failures from other things soon. Does Haiku have low limits here? It was a problem on OS X for the first couple of releases because the default values hadn’t changed since OPENSTEP 4, I had a script that set the sysctl values to a couple of orders of magnitude higher than the default to prevent things dying, but after 10.4 Apple made the defaults sensible.
It was essential for Capsicum because you lose access to the global namespace once you enter capability mode and so can’t open the device mode. You’d need libc to open the device before you called cap_enter and that might have surprising effects (in particular, code often does closefrom just after for some defence in depth against things being accidentally opened concurrently). I believe Linux did it for similar reasons (seccomp-bpf policies wanting to disallow open and not being able to special case a particular path because BPF can’t see into string arguments).
I imagine the perf wouldn’t have been an issue indeed, but we wanted to do things correctly nonetheless.
I don’t think our limits are especially low. We’ve raised them now and again when big applications come along, but it’s been a while since we’ve needed to do that, I think.