Lots of null pointer dereferences, use-after-free, and double free. OpenBSD really needs a language with affine types or smart pointers that integrates with C. ;)
Im sure they could build the language or C extensions given they built a whole OS and maintained (still do?) a compiler for it. It would also help them achieve their security goals better than their developers are doing now with C language. A good investment I’d say.
This could happen if one or more people with interest and motivation showed up and managed to work well with the project to integrate this with the system as yet another form of mitigation.
As for the existing devs, they are all already very busy scratching their own itches and pursue their own ideas, some related to security, some not. And generally they don’t like to be told what to work on in the time they volunteer.
I realize this is mostly bikeshedding, but does the core team regularly (or ever) consider this? Or is this seen as too much overhead - learning the subtleties of a new language/implementation on top of the difficulty of os/kernel development. I would think the D language folks would love to team up with one of the BSDs to focus on whatever language demands the OS team would come up with.
I second this question. That’s a big number for security-focused OS. Might be reasonable, too, given it’s monolithic kernel with batteries included. I did a quick check on the site. Didn’t see a full list of system calls.
Lots of null pointer dereferences, use-after-free, and double free. OpenBSD really needs a language with affine types or smart pointers that integrates with C. ;)
Such a language needs to work on every hardware platform they support and have a BSD licensed compiler/toolchain 🙃
Im sure they could build the language or C extensions given they built a whole OS and maintained (still do?) a compiler for it. It would also help them achieve their security goals better than their developers are doing now with C language. A good investment I’d say.
This could happen if one or more people with interest and motivation showed up and managed to work well with the project to integrate this with the system as yet another form of mitigation.
As for the existing devs, they are all already very busy scratching their own itches and pursue their own ideas, some related to security, some not. And generally they don’t like to be told what to work on in the time they volunteer.
I realize this is mostly bikeshedding, but does the core team regularly (or ever) consider this? Or is this seen as too much overhead - learning the subtleties of a new language/implementation on top of the difficulty of os/kernel development. I would think the D language folks would love to team up with one of the BSDs to focus on whatever language demands the OS team would come up with.
I actually think starting to use C++ in kernel is no-brainer, like GCC did. C++ doesn’t have hardware or toolchain problem, does it?
I’m not familiar with the size of the OpenBSD kernel, can anyone give a sense of what fraction of the kernel 226 syscalls is?
That’s pretty close to every syscall I believe. The last syscall is 330, but there are several large gaps.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/syscalls.master?rev=1.188&content-type=text/x-cvsweb-markup
syscalls like ioctl() trigger so many code paths that it would make sense to count each ioctl type as a separate syscall for purposes of fuzzing.
I second this question. That’s a big number for security-focused OS. Might be reasonable, too, given it’s monolithic kernel with batteries included. I did a quick check on the site. Didn’t see a full list of system calls.