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. ;)
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.
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.
The idea of a slightly modified C which would somehow prevent use-after-free and similar bugs is good. It’s similar to other ideas OpenBSD has already realized such as adding C API functions which are easier to use safely, or hardening of the C run-time against ROP. And it’s not as if the C we’re writing did not contain non-standard extensions already (packed structs, gcc-isms inherited by clang, etc.)
Now, where are some compiler-writing C langauge lawyer academics with the needed skills who would sit down with a bunch of OpenBSD hackers and volunteer a lot of their spare time for this? In over 10 years of involvement with the project I’ve never met a person with this skill set. In a volunteer project you have to work with the skills you happen to get.
Glad you’re open to the possibility if you had help for it. The people behind Clay and Cyclone might have helped given they were already doing hardest parts. It’s possible you didn’t know those languages exist. The folks good at researching and developing languages usually aren’t good at polish, outreach, and so on.
It’s possible we need a sponsor organization or new type of volunteer for such a role. One that’s a middle-person between the team with time to build compilers and the people that would use them. Such a person would need to be able to influence compiler developers to ensure they don’t do anything that kills adoption. I figure there’d be a lot of negotiations with middle person doing tie breakers on stuff people were divided on. Probably also need to be a compiler developer themselves so they can do the polish, packaging, and later maintenance.
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’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.
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.
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.
The idea of a slightly modified C which would somehow prevent use-after-free and similar bugs is good. It’s similar to other ideas OpenBSD has already realized such as adding C API functions which are easier to use safely, or hardening of the C run-time against ROP. And it’s not as if the C we’re writing did not contain non-standard extensions already (packed structs, gcc-isms inherited by clang, etc.)
Now, where are some compiler-writing C langauge lawyer academics with the needed skills who would sit down with a bunch of OpenBSD hackers and volunteer a lot of their spare time for this? In over 10 years of involvement with the project I’ve never met a person with this skill set. In a volunteer project you have to work with the skills you happen to get.
Glad you’re open to the possibility if you had help for it. The people behind Clay and Cyclone might have helped given they were already doing hardest parts. It’s possible you didn’t know those languages exist. The folks good at researching and developing languages usually aren’t good at polish, outreach, and so on.
It’s possible we need a sponsor organization or new type of volunteer for such a role. One that’s a middle-person between the team with time to build compilers and the people that would use them. Such a person would need to be able to influence compiler developers to ensure they don’t do anything that kills adoption. I figure there’d be a lot of negotiations with middle person doing tie breakers on stuff people were divided on. Probably also need to be a compiler developer themselves so they can do the polish, packaging, and later maintenance.
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.