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. ;)
Although Iām against C++, itās clearly an option with more safety features and low-cost abstractions all the time. Iāll note that folks developing L4 microkernels and Genode started using it for those reasons. At this point, Iād rather whatever it is be a safer C with better abstractions that outputs vanilla C. That would solve most of tooling and integration issues that come with language switch. It also dodges C++ās huge complexity. Itās ridiculously complex.
Itās close! Iām eyeballing it for that use with Brute-Force Assurance. It would have way more acceptance than a Scheme-based solution. Iād have to swap its syntax out since C developers switch to C-like languages more than Python-like languages. The compiler for this purpose should produce C that looks like what a person would write more than a machine. It should at least be an option. Lets it get used incrementally in existing, C projects. Finally, the people I see online griping about the compiler means they need to focus hard on getting it in good shape or someone has to build a separate, certifying compiler.
So, thatās what I was thinking when I assessed Nim as C replacement in general and for safety critical. Oh yeah, contracts! Frama-C or Ada-style contracts supported by default. Lets you encode whatever extra stuff the type system doesnāt already handle. I donāt know if they have contracts.
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.
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.
Exactly. The average coder in Rust is currently outperforming the OpenBSD team on these kinds of bugs due to type system. That means these bugs happen since they donāt care enough to prevent them. Theyāre about QA and mitigation tech up to a certain point with certain bug-adding tech (eg C language). Past that point or with different mitigations (esp language), they start making excuses about time, itches, and so on. Iāll keep pointing this out every time evidence of easily-prevented bugs comes in. Maybe something will click in a readerās head that leads to a solution.
Many of them also tell other people how they should be doing UNIX design, quality or security. Sometimes even in a snooty way. They like doing that despite aggravation it might cause others. You say those same people donāt like āto be toldā they should use more secure tech in a security-focused project. It sounds like thereās a life lesson in there somewhere on top of some security lessons.
Thatās a tad inflammatory nay? Suggesting that not using rust in tantamount to not caring. Its not like the Linux/BSD kernel could be rewritten in rust in a day, there is 20+ years of development in there.
And while its not exactly a fair compairson as its been run against linux for longer, 9 issues (which have been fixed) versus quite a few in linux suggests something in OpenBSD is working.
Yeah, a tad inflammatory to match the style of their mailing lists talking about other OSās or hardware vendors not doing enough for security. I always give them credit for their strong points of simplified UNIX, code review/quality, mitigations, and great documentation. Plus, I like a few of them personally.
Far as your counterpoint, itās a strawman (full rewrite) thatās not even what Im proposing. Iām saying folks that cared seeing the language cause issues would make a safer version like others did in other projects (eg Clay, Cyclone). One highly-compatible with C. Theyād write new code in that language. The extensive rewrites of existing code they already do would be done in that language. Over time (years), most or all the OS would be converted to the safer language. Someone might even write tools to automate this.
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 š
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?
Although Iām against C++, itās clearly an option with more safety features and low-cost abstractions all the time. Iāll note that folks developing L4 microkernels and Genode started using it for those reasons. At this point, Iād rather whatever it is be a safer C with better abstractions that outputs vanilla C. That would solve most of tooling and integration issues that come with language switch. It also dodges C++ās huge complexity. Itās ridiculously complex.
Sounds like Nim to me. MIT license.
Itās close! Iām eyeballing it for that use with Brute-Force Assurance. It would have way more acceptance than a Scheme-based solution. Iād have to swap its syntax out since C developers switch to C-like languages more than Python-like languages. The compiler for this purpose should produce C that looks like what a person would write more than a machine. It should at least be an option. Lets it get used incrementally in existing, C projects. Finally, the people I see online griping about the compiler means they need to focus hard on getting it in good shape or someone has to build a separate, certifying compiler.
So, thatās what I was thinking when I assessed Nim as C replacement in general and for safety critical. Oh yeah, contracts! Frama-C or Ada-style contracts supported by default. Lets you encode whatever extra stuff the type system doesnāt already handle. I donāt know if they have contracts.
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.
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.
Exactly. The average coder in Rust is currently outperforming the OpenBSD team on these kinds of bugs due to type system. That means these bugs happen since they donāt care enough to prevent them. Theyāre about QA and mitigation tech up to a certain point with certain bug-adding tech (eg C language). Past that point or with different mitigations (esp language), they start making excuses about time, itches, and so on. Iāll keep pointing this out every time evidence of easily-prevented bugs comes in. Maybe something will click in a readerās head that leads to a solution.
Many of them also tell other people how they should be doing UNIX design, quality or security. Sometimes even in a snooty way. They like doing that despite aggravation it might cause others. You say those same people donāt like āto be toldā they should use more secure tech in a security-focused project. It sounds like thereās a life lesson in there somewhere on top of some security lessons.
Thatās a tad inflammatory nay? Suggesting that not using rust in tantamount to not caring. Its not like the Linux/BSD kernel could be rewritten in rust in a day, there is 20+ years of development in there.
And while its not exactly a fair compairson as its been run against linux for longer, 9 issues (which have been fixed) versus quite a few in linux suggests something in OpenBSD is working.
Yeah, a tad inflammatory to match the style of their mailing lists talking about other OSās or hardware vendors not doing enough for security. I always give them credit for their strong points of simplified UNIX, code review/quality, mitigations, and great documentation. Plus, I like a few of them personally.
Far as your counterpoint, itās a strawman (full rewrite) thatās not even what Im proposing. Iām saying folks that cared seeing the language cause issues would make a safer version like others did in other projects (eg Clay, Cyclone). One highly-compatible with C. Theyād write new code in that language. The extensive rewrites of existing code they already do would be done in that language. Over time (years), most or all the OS would be converted to the safer language. Someone might even write tools to automate this.
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.