4 ms·

We will port our security critical code to Rust when you can ship it in Rust for Mac, iOS, Android, Windows, Linux, BSD, FreeRTOS, SYSBIOS, and VxWorks. C's do

by api 10y ago

We will port our security critical code to Rust when you can ship it in Rust for Mac, iOS, Android, Windows, Linux, BSD, FreeRTOS, SYSBIOS, and VxWorks. C's dominance today is about platform and architectural support, not hardware constraints. It's the JavaScript of systems programming.

nickpsecurity 10y ago
Can't you do a reference implementation in a language with great static checks like Rust with an equivalent one in C/C++ side-by-side? From Orange Book A1 to modern seL4, they always did something like that where high-level problem is expressed in analyzable way with equivalent, low-level code. Always found problems testing missed. In your case, SPARK would prevent all kinds of problems with Rust's discipline possibly reducing those temporal errors. Note: Many safer languages can also compile down to C and integrate it with FFI with type-checked wrappers. Classic strategy for dealing with ecosystem problem. I can't recall if Rust has one. It should. Note 2: You look to maybe have over-constrained yourself with supported platforms, too. Only four on that list are critical.
- api 10y ago
  What we do right now in our project is write thin C++ but use C++'s features (class types, exceptions, catch all, etc.) to implement bounds checking in parsers, etc., in a relatively safe way and with near-zero cost. If we need to go to plain C later we can "minus minus" this thin C++ code base relatively easily. We could in theory do the same with Rust but it would be more work since it's not as syntactically close. C++ is available almost everywhere C is available, so it's an acceptable compromise. We also fuzz any "C-like" parser code, of which there is not much. I am really optimistic about Rust. I think it's the only thing with a chance to displace C in systems coding. (Go is too intrinsically heavy for tiny devices and has other issues.) But it has a long road ahead to work its way into all the corners of computing that we need to target in practice. I wasn't hating on it, just pointing out how hard it is to displace an inferior language with a monstrous install base. Look at JavaScript. Edit: here's an idea: what about a Rust-to-C transplier? How practical would it be to implement such a thing well enough to allow it to be used for low-level systems programming?
  - steveklabnik 10y ago
    There is a very very early work in progress one, but it's not nearly ready for non-toy programs yet, it doesn't transpile nearly all of C. Gotta start somewhere!
  - nickpsecurity 10y ago
    "write thin C++ but use C++'s features " Well, that's good given I previously told you that your best approach to memory safety... given C++ use... was to convert it to C to run through Softbound+CETS or something similar. Alternatively, a C++ to C compiler then that. I wonder what the state of C++-to-C compilers is these days in terms of what they take in and quality of output.
- steveklabnik 10y ago
  Rust has zero-overhead calls into C, but no production-ready transpiler yet.
steveklabnik 10y ago
A lot of those platforms should be covered; I'm not mega familiar with the RTOses you mention, SH-4 is one arch that I'm pretty sure nobody has done a port of yet, though it seems like LLVM supports it?

by api 10y ago

nickpsecurity 10y ago

Can't you do a reference implementation in a language with great static checks like Rust with an equivalent one in C/C++ side-by-side? From Orange Book A1 to modern seL4, they always did something like that where high-level problem is expressed in analyzable way with equivalent, low-level code. Always found problems testing missed. In your case, SPARK would prevent all kinds of problems with Rust's discipline possibly reducing those temporal errors. Note: Many safer languages can also compile down to C and integrate it with FFI with type-checked wrappers. Classic strategy for dealing with ecosystem problem. I can't recall if Rust has one. It should. Note 2: You look to maybe have over-constrained yourself with supported platforms, too. Only four on that list are critical.

api 10y ago
What we do right now in our project is write thin C++ but use C++'s features (class types, exceptions, catch all, etc.) to implement bounds checking in parsers, etc., in a relatively safe way and with near-zero cost. If we need to go to plain C later we can "minus minus" this thin C++ code base relatively easily. We could in theory do the same with Rust but it would be more work since it's not as syntactically close. C++ is available almost everywhere C is available, so it's an acceptable compromise. We also fuzz any "C-like" parser code, of which there is not much. I am really optimistic about Rust. I think it's the only thing with a chance to displace C in systems coding. (Go is too intrinsically heavy for tiny devices and has other issues.) But it has a long road ahead to work its way into all the corners of computing that we need to target in practice. I wasn't hating on it, just pointing out how hard it is to displace an inferior language with a monstrous install base. Look at JavaScript. Edit: here's an idea: what about a Rust-to-C transplier? How practical would it be to implement such a thing well enough to allow it to be used for low-level systems programming?
- steveklabnik 10y ago
  There is a very very early work in progress one, but it's not nearly ready for non-toy programs yet, it doesn't transpile nearly all of C. Gotta start somewhere!
- nickpsecurity 10y ago
  "write thin C++ but use C++'s features " Well, that's good given I previously told you that your best approach to memory safety... given C++ use... was to convert it to C to run through Softbound+CETS or something similar. Alternatively, a C++ to C compiler then that. I wonder what the state of C++-to-C compilers is these days in terms of what they take in and quality of output.
steveklabnik 10y ago
Rust has zero-overhead calls into C, but no production-ready transpiler yet.

steveklabnik 10y ago

A lot of those platforms should be covered; I'm not mega familiar with the RTOses you mention, SH-4 is one arch that I'm pretty sure nobody has done a port of yet, though it seems like LLVM supports it?