Fantastic to see kqueue on Haiku! I’m surprised that they made .NET work, the .NET use of kqueue upstream makes a few assumptions about kqueue behaviour that are specific to the XNU implementation.
trungnt2910 made socketpair() work for non-STREAM sockets, meaning that UNIX domain sockets can now be created this way
I’m not sure what this means, AF_UNIX sockets can be SOCK_STREAM. Does this mean that it can now create SOCK_SEQPACKET sockets? If so, that’s a big quality of life improvement.
Does Haiku have clang support yet? Last time I looked it was GCC only and the prospect of having to use GCC put me off.
the .NET use of kqueue upstream makes a few assumptions about kqueue behaviour that are specific to the XNU implementation.
At present it’s only used for .NET socket notifications, which are pretty simple. Are you sure it really makes assumptions about XNU behavior? (There was kqueue use in a different component that made use of the “data” field, this component however didn’t even have an epoll version and so that was easy enough to disable for the present.)
Does this mean that it can now create SOCK_SEQPACKET sockets? If so, that’s a big quality of life improvement.
No, it means it can also be used for AF_UNIXSOCK_DGRAM, which were also implemented last month (and also noted in the activity report.)
Haiku does define SOCK_SEQPACKET in our headers, but I don’t think anything implements it at the moment. If you have a use-case (and ideally, test-case), I suppose you can open a ticket.
Does Haiku have clang support yet? Last time I looked it was GCC only and the prospect of having to use GCC put me off.
We’ve had clang in the software depots for a while, and there’s some packages that are always compiled with it, so yes. However, there are still some issues compiling Haiku itself with clang, and I think there’s at least one issue about Haiku’s own headers tripping up on clang’s -Werror (our non-varargs ioctl that wants a default parameter; there’s WIP changes to fix that, but as it’s only an issue for C, not C++, and only with clang and -Werror, it hasn’t gotten much attention.)
At present it’s only used for .NET socket notifications, which are pretty simple. Are you sure it really makes assumptions about XNU behavior?
I don’t remember the details, but I think it was in the filesystem watcher interface. The macOS implementation had some subtle differences to the FreeBSD one that needed working around.
Haiku does define SOCK_SEQPACKET in our headers, but I don’t think anything implements it at the moment. If you have a use-case (and ideally, test-case), I suppose you can open a ticket.
SOCK_SEQPACKET is basically my default for AF_UNIX things now. Every SOCK_STREAM thing that I’ve ever implemented with it has tried to implement a message-oriented system on top of the stream, relying on the kernel to do this removes a load of complexity in userspace. On FreeBSD, devd re-exports the kernel messages over a seqpacket socket, which is great for consumers: every recvmsg receives exactly one devd event.
We’ve had clang in the software depots for a while, and there’s some packages that are always compiled with it, so yes.
Great! Last time I looked there was a port of a very old version, but it looks as if it’s getting closer (16 is almost landed but 17 is in RC state upstream).
but I think it was in the filesystem watcher interface.
Ah, well, I didn’t implement that. I considered it, but Haiku’s filesystem notification system is pretty different from what kqueue provides, so for the moment I didn’t. It looked like libuv separated filesystem events from the rest of the event system, at least, though of course for kqueue it’s in the same interface.
Every SOCK_STREAM thing that I’ve ever implemented with it has tried to implement a message-oriented system on top of the stream, relying on the kernel to do this removes a load of complexity in userspace.
What’s the difference between SOCK_DGRAM? Guaranteed in-order message delivery, I guess?
Pretty sure most AF_UNIX+SOCK_DGRAM implementations won’t drop packets except maybe under certain shutdown conditions, not sure. Either way, it likely wouldn’t be too hard to implement then, but it’s probably not any sort of priority for us.
What’s the difference between SOCK_DGRAM? Guaranteed in-order message delivery, I guess?
Yes, exactly.
Pretty sure most AF_UNIX+SOCK_DGRAM implementations won’t drop packets except maybe under certain shutdown conditions, not sure.
There are often places in kernel buffers where they can be dropped or reordered. If your data gram implementation already provides the relevant guarantees then you can probably implement it trivially.
Well, there’s more than “none”, and more than a lot of OSes had in the 90s/00s. We have SMAP/SMEP, NX bit, ASLR (including kernel ASLR), filesystem permissions checks (though these haven’t been battle-tested, since the GUI runs as root and very few users bother to useradd & su to a non-root user), syscall permissions checks (though these haven’t been fully audited or battle-tested either), and more.
TIL! Last I heard an official statement there was no prioritization of security features. Clearly I’m out of the loop! Any plans on supporting disk encryption?
Well, the statement is correct: they’re not a priority, but we have some anyway.
There is/was third-party support (though developed by a long-time project member) for disk encryption, but only off the boot disk. There are no immediate plans to incorporate that and support boot disk encryption at the moment, I don’t think.
Are there any plams to automatically create a non-root user on install and use it as the default? This is how I believe macos does it, prompting for a root password when needed.
FWIW testing Haiku is eternally on my “when I have time” list, and for a lot of cases I’d love to ditch unixes for a simple single-user OS, but that user doesn’t have to be root if the separation is for security purposes ;)
There aren’t really any particular plans to do any security enhancements. Sometimes developers work on them, but they’re indeed not presently on any priority list. So, I guess the answer is “no”.
Fantastic to see kqueue on Haiku! I’m surprised that they made .NET work, the .NET use of kqueue upstream makes a few assumptions about kqueue behaviour that are specific to the XNU implementation.
I’m not sure what this means,
AF_UNIXsockets can beSOCK_STREAM. Does this mean that it can now createSOCK_SEQPACKETsockets? If so, that’s a big quality of life improvement.Does Haiku have clang support yet? Last time I looked it was GCC only and the prospect of having to use GCC put me off.
At present it’s only used for .NET socket notifications, which are pretty simple. Are you sure it really makes assumptions about XNU behavior? (There was kqueue use in a different component that made use of the “data” field, this component however didn’t even have an epoll version and so that was easy enough to disable for the present.)
No, it means it can also be used for
AF_UNIXSOCK_DGRAM, which were also implemented last month (and also noted in the activity report.)Haiku does define
SOCK_SEQPACKETin our headers, but I don’t think anything implements it at the moment. If you have a use-case (and ideally, test-case), I suppose you can open a ticket.We’ve had clang in the software depots for a while, and there’s some packages that are always compiled with it, so yes. However, there are still some issues compiling Haiku itself with clang, and I think there’s at least one issue about Haiku’s own headers tripping up on clang’s -Werror (our non-varargs
ioctlthat wants a default parameter; there’s WIP changes to fix that, but as it’s only an issue for C, not C++, and only with clang and -Werror, it hasn’t gotten much attention.)I don’t remember the details, but I think it was in the filesystem watcher interface. The macOS implementation had some subtle differences to the FreeBSD one that needed working around.
SOCK_SEQPACKET is basically my default for AF_UNIX things now. Every SOCK_STREAM thing that I’ve ever implemented with it has tried to implement a message-oriented system on top of the stream, relying on the kernel to do this removes a load of complexity in userspace. On FreeBSD, devd re-exports the kernel messages over a seqpacket socket, which is great for consumers: every recvmsg receives exactly one devd event.
Great! Last time I looked there was a port of a very old version, but it looks as if it’s getting closer (16 is almost landed but 17 is in RC state upstream).
Ah, well, I didn’t implement that. I considered it, but Haiku’s filesystem notification system is pretty different from what kqueue provides, so for the moment I didn’t. It looked like
libuvseparated filesystem events from the rest of the event system, at least, though of course for kqueue it’s in the same interface.What’s the difference between SOCK_DGRAM? Guaranteed in-order message delivery, I guess?
Pretty sure most AF_UNIX+SOCK_DGRAM implementations won’t drop packets except maybe under certain shutdown conditions, not sure. Either way, it likely wouldn’t be too hard to implement then, but it’s probably not any sort of priority for us.
Yes, exactly.
There are often places in kernel buffers where they can be dropped or reordered. If your data gram implementation already provides the relevant guarantees then you can probably implement it trivially.
Does anyone actually use Haiku as a daily driver? I’m curious how their experience has been.
Action Retro did a video on it https://youtu.be/UByttyMHDr8
All I want is a Haiku with some security guarantees. Any security guarantees other than “there are none”.
Well, there’s more than “none”, and more than a lot of OSes had in the 90s/00s. We have SMAP/SMEP, NX bit, ASLR (including kernel ASLR), filesystem permissions checks (though these haven’t been battle-tested, since the GUI runs as root and very few users bother to
useradd&suto a non-root user), syscall permissions checks (though these haven’t been fully audited or battle-tested either), and more.TIL! Last I heard an official statement there was no prioritization of security features. Clearly I’m out of the loop! Any plans on supporting disk encryption?
Well, the statement is correct: they’re not a priority, but we have some anyway.
There is/was third-party support (though developed by a long-time project member) for disk encryption, but only off the boot disk. There are no immediate plans to incorporate that and support boot disk encryption at the moment, I don’t think.
Are there any plams to automatically create a non-root user on install and use it as the default? This is how I believe macos does it, prompting for a root password when needed.
FWIW testing Haiku is eternally on my “when I have time” list, and for a lot of cases I’d love to ditch unixes for a simple single-user OS, but that user doesn’t have to be root if the separation is for security purposes ;)
There aren’t really any particular plans to do any security enhancements. Sometimes developers work on them, but they’re indeed not presently on any priority list. So, I guess the answer is “no”.