6 ms·

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2 https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

by ninjin 3y ago

hedora 3y ago
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.
- abound 3y ago
  > 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/26197104b7bb9a5a35db243d639aee6e46d35d75/text/0560-integer-overflow.md https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... [2] https://stackoverflow.com/a/60238510 https://stackoverflow.com/a/60238510
- ninjin 3y ago
  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 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.
  - nextaccountic 3y ago
    This is all true, but this just means that any security focused OS for the next 40 years should consider Rust
    - bayindirh 3y ago
      Rust brings niceties, but this implies no requirement for considering Rust.
    - ninjin 3y ago
      Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with the complexity of your codebase and what it interacts with. If you want to rewrite your video processing service which you wrote together with five or so contributors and is say 20,000 lines of C++ into Rust, that is one thing. Take a step back and consider the number of users and what you interact with, it all seems rather manageable and you can probably be backwards compatible with respect to your users. In terms of time, maybe a few months? Maybe even six? For a single programmer that now needs to learn proper Rust. Now, instead consider what an operating system is and the surface with which it interacts. The absolutely metric ton of hardware, the heap of standards, the massive load of hacks that are documented and undocumented, the large amount of users, the number of contributors and their experience, the platforms that you support, all the software that is written for your operating system to make it useful, etc. OpenBSD is famous (infamous?) for being willing to break things to do "the right thing". But they are also famous (infamous, again?) for being very conservative, which I think is understandable given their security focus and (relatively) low amount of manpower. Rust has certainly been considered, but it is far from the only consideration. This is akin to walking into a multi-million dollar company that has a fully functioning service or piece of software that they have been selling for decades and suggest to management that maybe we should start moving it all from C# to Rust next week, while being blissfully unaware of everything else the company is beholden to. Spoiler, it will not work out that way. Furthermore, it is somewhat tiring that Rust keeps being touted as the final revelation when it comes to writing safer code. Guess what, there were plenty of projects before Rust that introduced safety in various forms (and at various costs) and there will be plenty of projects after Rust that will do the same. Yes, it is an amazing piece of technology, but it is equally plausible that its influence may not end up in it eating the world; rather give birth to something else or bring some of its thinking into other languages. Only time will tell and worse may end up being better yet again. So to me, what any operating system (security focused or not) should do is to consider their (limited) options given their own goals and situation. Which is something I have seen plenty of evidence that a project of the age of OpenBSD is doing and successfully so. Personally, I am keeping an eye on Redox and look forward to see what lessons will be learnt from their take of what an operating system can be. But for my servers and desktop I have and continue (for now?) to run a healthy mix of Linux and BSD while getting work done.
- yakubin 3y ago
  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&edition=2021&gist=73ab2fde7f46f5d7e94b5156aa8951dd https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - yakubin 3y ago
    A similar warning could be enabled in GCC using the flag -Wsign-compare.
- 1over137 3y ago
  >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.
- piss_n_chips 3y ago
  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.
petee 3y ago
> Stonks only go up And the signature totally explains their childish reply, over there and here.
- MyMonkeyBalls 3y ago
  Yeah even a child like me is better at secure programming than Theo De Raadt
  - petee 3y ago
    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
    - MyMonkeyBalls 3y ago
      [flagged]
    - tiffanyh 3y ago
      Would a code analyzer have detected this bug? (E.g. Valgrind, Flexelint, cppcheck, clang static analyzer, etc.) If yes, then why aren't code analyzers used on all OpenBSD code submissions, given their stance on having correct code & security focused.
      - ori_b 3y ago
        No, probably not. It requires a crafted binary to be executed.

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2 https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

by ninjin 3y ago

This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2 https://marc.info/?l=openbsd-tech&m=170234892604404&w=2

hedora 3y ago

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.

abound 3y ago
> 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/26197104b7bb9a5a35db243d639aee6e46d35d75/text/0560-integer-overflow.md https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... [2] https://stackoverflow.com/a/60238510 https://stackoverflow.com/a/60238510
ninjin 3y ago
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 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.
- nextaccountic 3y ago
  This is all true, but this just means that any security focused OS for the next 40 years should consider Rust
  - bayindirh 3y ago
    Rust brings niceties, but this implies no requirement for considering Rust.
  - ninjin 3y ago
    Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with the complexity of your codebase and what it interacts with. If you want to rewrite your video processing service which you wrote together with five or so contributors and is say 20,000 lines of C++ into Rust, that is one thing. Take a step back and consider the number of users and what you interact with, it all seems rather manageable and you can probably be backwards compatible with respect to your users. In terms of time, maybe a few months? Maybe even six? For a single programmer that now needs to learn proper Rust. Now, instead consider what an operating system is and the surface with which it interacts. The absolutely metric ton of hardware, the heap of standards, the massive load of hacks that are documented and undocumented, the large amount of users, the number of contributors and their experience, the platforms that you support, all the software that is written for your operating system to make it useful, etc. OpenBSD is famous (infamous?) for being willing to break things to do "the right thing". But they are also famous (infamous, again?) for being very conservative, which I think is understandable given their security focus and (relatively) low amount of manpower. Rust has certainly been considered, but it is far from the only consideration. This is akin to walking into a multi-million dollar company that has a fully functioning service or piece of software that they have been selling for decades and suggest to management that maybe we should start moving it all from C# to Rust next week, while being blissfully unaware of everything else the company is beholden to. Spoiler, it will not work out that way. Furthermore, it is somewhat tiring that Rust keeps being touted as the final revelation when it comes to writing safer code. Guess what, there were plenty of projects before Rust that introduced safety in various forms (and at various costs) and there will be plenty of projects after Rust that will do the same. Yes, it is an amazing piece of technology, but it is equally plausible that its influence may not end up in it eating the world; rather give birth to something else or bring some of its thinking into other languages. Only time will tell and worse may end up being better yet again. So to me, what any operating system (security focused or not) should do is to consider their (limited) options given their own goals and situation. Which is something I have seen plenty of evidence that a project of the age of OpenBSD is doing and successfully so. Personally, I am keeping an eye on Redox and look forward to see what lessons will be learnt from their take of what an operating system can be. But for my servers and desktop I have and continue (for now?) to run a healthy mix of Linux and BSD while getting work done.
yakubin 3y ago
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&edition=2021&gist=73ab2fde7f46f5d7e94b5156aa8951dd https://play.rust-lang.org/?version=stable&mode=debug&editio...
- yakubin 3y ago
  A similar warning could be enabled in GCC using the flag -Wsign-compare.
1over137 3y ago
>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.
piss_n_chips 3y ago
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.

petee 3y ago

> Stonks only go up And the signature totally explains their childish reply, over there and here.

MyMonkeyBalls 3y ago
Yeah even a child like me is better at secure programming than Theo De Raadt
- petee 3y ago
  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
  - MyMonkeyBalls 3y ago
    [flagged]
  - tiffanyh 3y ago
    Would a code analyzer have detected this bug? (E.g. Valgrind, Flexelint, cppcheck, clang static analyzer, etc.) If yes, then why aren't code analyzers used on all OpenBSD code submissions, given their stance on having correct code & security focused.
    - ori_b 3y ago
      No, probably not. It requires a crafted binary to be executed.