At least FreeBSD's syscall ABI is guaranteed to be stable, one can run ancient binaries on a modern kernel. I believe the same is not true of OpenBSD and maybe NetBSD however.
The pf maintainer in FreeBSD has been doing a ton of work to bring more recent improvements over from OpenBSD, trying to bring them in sync as much as possible without breaking compatibility:…
A design that works by default isn't automatically better either though. You have to look at the details. > I guess one might be tempted to forgive a few warts in the interface layers ... well, yeah, that's exactly my…
The article clearly isn't talking about technical debt within the kernel implementations of epoll and kqueue, and if one wanted, it'd be easy to define fallback EVFILT_READ/WRITE filters using a device's poll…
Well, no, it's "this interface works fine for you if you implement it." The kernel doesn't magically know whether your device file has data available to read, your device file has to define what that means. That's all…
The same is true of kqueue/kevent though... the driver just needs to decide which filters it wants to implement. There's no need to extend kqueue when adding some custom driver or fd type. One just needs to define some…
For what it's worth, the default root shell is now /bin/sh instead of csh. I think that's true as of 14.0. /bin/sh is also a better interactive shell than it used to be, though yeah, I don't use it to do anything other…
CHERI does more than help eliminate security vulnerabilities. Consider that today we rely on the MMU to provide memory isolation between Unix processes; CHERI enables isolation without switching page tables, at a…
CHERI does permit tricks like storing flags in the low bits of a pointer, at least to some extent. Quite a lot of low level C code (including some in the CheriBSD kernel) needs that to work.
I use "ktrace -t f" once in a while for debugging and it's really handy. Output looks like 78436 cat PFLT 0x6c71f99cda8 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36c280 0x2<VM_PROT_WRITE>…
I'd be amazed if it isn't a configuration error of some kind.
How much data ends up being served from RAM? I had the impression that it was negligible and that the page cache was mostly used for file metadata and infrequently accessed data.
You can even send a Unix socket over itself. The kernel has to be careful to handle that correctly. :)
This is mostly true on FreeBSD as well. The real problem is that capability mode also disallows openat(AT_FDCWD) - there has to be an explicit directory descriptor.
It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap…
That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.
There's some discussion happening now and I do expect to see some process changes coming out of this. It's tricky. The review you link does nominally follow the process of creating a review and having some discussion,…
The notion there is that at some point in the past free memory was scarce, so the kernel swapped out some pages, and that swap space may still be in use long after the shortage is alleviated. FreeBSD won't swap anything…
> as many of these tests show The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.
"paravirtualized Solaris kernel" isn't really accurate - it's a collection of kernel interface shims. The whole thing is quite small, about 4KLOC on FreeBSD.
A driver is in ports while the author works on getting it ready to import. Just pkg install iichid.
Also mentioned here: https://lwn.net/Articles/808733/
I was wondering how this scheme might break applications that do clever things with a SIGBUS/SIGSEGV handler. Do you happen to know of any OSS that actually does something like this?
> I do wonder why there isn't an API for "lazy munmap()" You don't really need a separate API. The kernel can implement munmap() lazily, it just needs to also ensure that the address range isn't reused until a TLB…
If anyone is interested in their application to system software, the FreeBSD kernel uses a PID loop to regulate memory reclamation: https://svnweb.freebsd.org/base/head/sys/kern/subr_pidctrl.c...…
At least FreeBSD's syscall ABI is guaranteed to be stable, one can run ancient binaries on a modern kernel. I believe the same is not true of OpenBSD and maybe NetBSD however.
The pf maintainer in FreeBSD has been doing a ton of work to bring more recent improvements over from OpenBSD, trying to bring them in sync as much as possible without breaking compatibility:…
A design that works by default isn't automatically better either though. You have to look at the details. > I guess one might be tempted to forgive a few warts in the interface layers ... well, yeah, that's exactly my…
The article clearly isn't talking about technical debt within the kernel implementations of epoll and kqueue, and if one wanted, it'd be easy to define fallback EVFILT_READ/WRITE filters using a device's poll…
Well, no, it's "this interface works fine for you if you implement it." The kernel doesn't magically know whether your device file has data available to read, your device file has to define what that means. That's all…
The same is true of kqueue/kevent though... the driver just needs to decide which filters it wants to implement. There's no need to extend kqueue when adding some custom driver or fd type. One just needs to define some…
For what it's worth, the default root shell is now /bin/sh instead of csh. I think that's true as of 14.0. /bin/sh is also a better interactive shell than it used to be, though yeah, I don't use it to do anything other…
CHERI does more than help eliminate security vulnerabilities. Consider that today we rely on the MMU to provide memory isolation between Unix processes; CHERI enables isolation without switching page tables, at a…
CHERI does permit tricks like storing flags in the low bits of a pointer, at least to some extent. Quite a lot of low level C code (including some in the CheriBSD kernel) needs that to work.
I use "ktrace -t f" once in a while for debugging and it's really handy. Output looks like 78436 cat PFLT 0x6c71f99cda8 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36c280 0x2<VM_PROT_WRITE>…
I'd be amazed if it isn't a configuration error of some kind.
How much data ends up being served from RAM? I had the impression that it was negligible and that the page cache was mostly used for file metadata and infrequently accessed data.
You can even send a Unix socket over itself. The kernel has to be careful to handle that correctly. :)
This is mostly true on FreeBSD as well. The real problem is that capability mode also disallows openat(AT_FDCWD) - there has to be an explicit directory descriptor.
It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap…
That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.
There's some discussion happening now and I do expect to see some process changes coming out of this. It's tricky. The review you link does nominally follow the process of creating a review and having some discussion,…
The notion there is that at some point in the past free memory was scarce, so the kernel swapped out some pages, and that swap space may still be in use long after the shortage is alleviated. FreeBSD won't swap anything…
> as many of these tests show The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.
"paravirtualized Solaris kernel" isn't really accurate - it's a collection of kernel interface shims. The whole thing is quite small, about 4KLOC on FreeBSD.
A driver is in ports while the author works on getting it ready to import. Just pkg install iichid.
Also mentioned here: https://lwn.net/Articles/808733/
I was wondering how this scheme might break applications that do clever things with a SIGBUS/SIGSEGV handler. Do you happen to know of any OSS that actually does something like this?
> I do wonder why there isn't an API for "lazy munmap()" You don't really need a separate API. The kernel can implement munmap() lazily, it just needs to also ensure that the address range isn't reused until a TLB…
If anyone is interested in their application to system software, the FreeBSD kernel uses a PID loop to regulate memory reclamation: https://svnweb.freebsd.org/base/head/sys/kern/subr_pidctrl.c...…