One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default.
It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.)
I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer overflow/wraparound to trap, then add annotations or a special library call that supports modulo arithmetic as expected.
Look, I get as much as the next guy that Rust brings a lot of niceties. But what we are talking about here is a project that clocks in at just over 19,000,000 lines of C (`wc -l $(find src -name '*.c' -or -name '*.h')`), code heritage going back more than 40 years, an explicit commitment to a very rich set of platforms [1], and a very limited amount of manpower compared to projects such as Linux with their insane level of corporate backing. "Just rewrite it in and/or integrate Rust" is neither easy nor safe in that it overturns everything that is already there and tested.
As for improving upon C. I can not speak for OpenBSD as a project, but I am sure that there would be ample excitement to produce a minimal, solid C compiler with experimental security features to then serve as the default compiler for the project (heck, OpenBSD already ships with a number of less common security-related compiler flags from what I recall). Sadly, I doubt there is either funding or the hands to make that a reality.
IMHO the biggest blocker for Rust inside OpenBSD is that the project already has killed C developers and moving (some stuff) to Rust will need time and effort that could be put into other problems.
If they had to stabilize some parts, probably the answer would be different.
There are compiler flags that OpenBSD could be using but aren't, which would have caught this bug without needing to convert the codebase to Rust. Using -Wconversion would have warned on the mismatched signedness of the MAX macro argument (the unsigned integer, sysno) and its result (being assigned to npins, a signed integer). Alternatively, adding -fsanitize=implicit-integer-sign-change, or a UBSan flag that includes this, would detect this at runtime for the actual range of values that end up causing a change of sign.
Though, these would also be triggered by statements like:
pins[SYS_kbind] = -1;
Due to the pins array being of unsigned int, so all this sort of code would need to be fixed too.
In this case more important than any runtime overflow/underflow checks is the fact that the compiler will check that comparison operands are of the same type instead of inserting an implicit cast. Instead the programmer is forced to insert an explicit conversion like .try_into().unwrap(), which clearly suggests the possibility of an error. And if the error isn't handled, it will panic.
Then report the bug like an adult instead of acting like you found some huge published vulnerability in code that was posted for peer review. Thats why the code is there, so others can identify issues; congrats, you did.
One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default.
It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.)
I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer overflow/wraparound to trap, then add annotations or a special library call that supports modulo arithmetic as expected.
Look, I get as much as the next guy that Rust brings a lot of niceties. But what we are talking about here is a project that clocks in at just over 19,000,000 lines of C (`wc -l $(find src -name '*.c' -or -name '*.h')`), code heritage going back more than 40 years, an explicit commitment to a very rich set of platforms [1], and a very limited amount of manpower compared to projects such as Linux with their insane level of corporate backing. "Just rewrite it in and/or integrate Rust" is neither easy nor safe in that it overturns everything that is already there and tested.
[1]: https://www.openbsd.org/plat.html
As for improving upon C. I can not speak for OpenBSD as a project, but I am sure that there would be ample excitement to produce a minimal, solid C compiler with experimental security features to then serve as the default compiler for the project (heck, OpenBSD already ships with a number of less common security-related compiler flags from what I recall). Sadly, I doubt there is either funding or the hands to make that a reality.
This is all true, but this just means that any security focused OS for the next 40 years should consider Rust
7 replies →
IMHO the biggest blocker for Rust inside OpenBSD is that the project already has killed C developers and moving (some stuff) to Rust will need time and effort that could be put into other problems.
If they had to stabilize some parts, probably the answer would be different.
2 replies →
> One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default.
I think this is only true on debug builds, with --release (which most Rust binaries an end-user uses should be compiled with) it just wraps [1] [2]
[1] https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... [2] https://stackoverflow.com/a/60238510
There are compiler flags that OpenBSD could be using but aren't, which would have caught this bug without needing to convert the codebase to Rust. Using -Wconversion would have warned on the mismatched signedness of the MAX macro argument (the unsigned integer, sysno) and its result (being assigned to npins, a signed integer). Alternatively, adding -fsanitize=implicit-integer-sign-change, or a UBSan flag that includes this, would detect this at runtime for the actual range of values that end up causing a change of sign.
Though, these would also be triggered by statements like:
Due to the pins array being of unsigned int, so all this sort of code would need to be fixed too.
In this case more important than any runtime overflow/underflow checks is the fact that the compiler will check that comparison operands are of the same type instead of inserting an implicit cast. Instead the programmer is forced to insert an explicit conversion like .try_into().unwrap(), which clearly suggests the possibility of an error. And if the error isn't handled, it will panic.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
A similar warning could be enabled in GCC using the flag -Wsign-compare.
>I wonder how hard it would be to backport the integer behavior to C.
Clang and gcc have flags that can make integer overflow trap.
> Stonks only go up
And the signature totally explains their childish reply, over there and here.
Yeah even a child like me is better at secure programming than Theo De Raadt
Then report the bug like an adult instead of acting like you found some huge published vulnerability in code that was posted for peer review. Thats why the code is there, so others can identify issues; congrats, you did.
People make mistakes in every project. So grow up
3 replies →