14 ms·

Prossimo – Memory safety for the Internet's most critical infrastructure

130 points by eplanit 5y ago

sometimesshit 5y ago
"Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers."
- baybal2 5y ago
  That made me laugh. Can people treat such people seriously when they obviously aren't? Dumb, aggressive promotion is characteristic of "trendy hipster projects" usually abandoned once the "cred" harvest is finished, and people involved go on.
  - bombela 5y ago
    It's both funny and true at the same time. I used to advertise my worth in how good my C++ is. Until I had a dumb after free error after git merging two adjacent line in the wrong order. A simple vector push done after capturing vector.begin instead of before. Nobody saw that in code review. Even reviews from C++ experts at the company. Of course it took 6 months until the first segfault. Invalidating 6 months of work. Rust would have not compiled. As simple as that. Now imagine if you could write code without living in fear of making everything blow up because of a single moment of weakness. That's Rust for me.
    - saagarjha 5y ago
      > Invalidating 6 months of work. What kind of system was this where a bug would literally invalidate all results from the moment it was introduced?
      - grumblenum 5y ago
        It’s just another of many testimonials of projects that will not be named at companies that will not be disclosed with implausible circumstances or unlikely details here to convince you that you had better switch your tech stack to this brand new thing before you too become a cautionary tale.
        bombela 5y ago
        Google. Backup of filers. Conversion from NetApp filer dumps to tarball. I did open source a prototype of the tool. I don't know if it has the bug. The final version was to Google standard of C++ and maybe some cleaner abstractions. https://github.com/bombela/dump2tar https://github.com/bombela/dump2tar
  - tptacek 5y ago
    These people are obviously serious.
  - topspin 5y ago
    It would be funny if they couldn't cite an endless stream of evidence for their argument. They can, however. And it's not going to stop. That's the thing about the memory safety argument; the people making it have an endless supply of ammunition, resupplied daily.
    - opnitro 5y ago
      See: https://twitter.com/LazyFishBarrel https://twitter.com/LazyFishBarrel
- dang 5y ago
  Please keep unsubstantive comments and flamebait off HN. Programming language flamewars are particularly tedious and particularly avoidable, so please avoid them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
xvilka 5y ago
Finishing Firefox oxidation[1] should become a priority too. Also, combining all separate modern alternatives[2] to coreutils and such in Rust, like exa, dust, etc into one umbrella project. [1] https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation [2] https://github.com/ibraheemdev/modern-unix https://github.com/ibraheemdev/modern-unix
- dochtman 5y ago
  See also https://github.com/uutils/coreutils/ https://github.com/uutils/coreutils/
- nerdponx 5y ago
  I love that Rust has become a successful systems language with memory safety. And while I use many of these "coreutils replacements" frequently, they are mostly not equivalent to the originals, and I think it's disingenuous to claim that they are.
  - tialaramex 5y ago
    They aren't drop-in replacements, but I think "equivalents" is fair. Your existing bash scripts don't work in an alternate universe where computers come with ripgrep not grep, but that universe isn't very different otherwise. Some things are a little easier to do, some things are a little harder to do, there are different bugs than in our universe, but it's way less strange than a universe where Lisp Machines still dominate, or even one where the Network uses X.25 rather than IP.
  - justaj 5y ago
    I think https://github.com/uutils/coreutils https://github.com/uutils/coreutils is aiming to provide drop-in replacements.
- Ericson2314 5y ago
  Good luck getting Google to fund that one particular go, heh. Even if they do fund Mozilla.
px43 5y ago
Eh, memory safety hasn't ever really been the problem with mod_tls, or curl, but it would be nice to have some solid examples for other projects to build on. The Linux kernel project sounds interesting. It would be nice if there was an effort to purge as much C code as possible from the core of the kernel and really enforce standards such that even a maliciously designed kernel module should not be vulnerable to memory corruption bugs.
- deleted 5y ago
  [deleted]
- topspin 5y ago
  Here[1] is the ongoing list of "curl security problems." Note the several memory safety related issues. The two most recent are: May 26, 2021 CWE-416: Use After Free May 26, 2021 CWE-457: Use of Uninitialized Variable There are numerous others that follow including out-of-bounds reads, overflows, etc. I can't imagine where you got the idea that this somehow "hasn't ever really been" a problem for curl. [1] https://curl.se/docs/security.html https://curl.se/docs/security.html
- simion314 5y ago
  Why not have all this Rust energy focused on a new kernel (not a toy/experiment), a kernel architect ed not evolved. You would get better results and if you need Linux compatibility add support for it from the start in soem kind of emulation/compatibility layer. Putting Rust into kernel seems to me that is a lot of effor for microscopic gains.
  - aaomidi 5y ago
    A new kernel has a massive uphill battle to fight to get to where Linux is today. Like, an absolutely huge battle to fight. Although it would be great to eventually see it.
    - simion314 5y ago
      I know, but Linux will not be forever, someone will start a new kernel that will replace it. All this giant tech companies could afford to pay some experienced people to start working on it. The initial scope would be limited but if the architecture and the language combo would give it a performance and security boost then for sure it will be adopted and new contributors would appear. If the performance/security would be similar to Linux/BSD then for sure the progress would be very slow.
deleted 5y ago
[deleted]
oscargrouch 5y ago
TIL: That there's an ORG to effectively harass people like Daniel Stenberg to rewrite popular stuff in Rust. To the Internet Security Research Group just fuck you! you will take my C++ out of my dead cold hands. I've never expected to see fascist ideology to get encoded into language culture. Lets make it even better, why don't we all get back to typewriters giving there will be no more bugs? There is a right way to do it: Do your own cool things in Rust. It will get popular and the language will get there eventually. This is not the right way, as developers are formed over technologies and their knowledge is even more important than the tools. Rust will form developers that will do great things, if C++ is a thing of the past it will get obsolete organically. Please rewrite Linux in Rust if you wish but leave Linus Torvalds alone. I cant wait for the next Rust driver module to freeze my flawless Linux in "dirty" C..
- mwcampbell 5y ago
  > TIL: That there's an ORG to effectively harass people like Daniel Stenberg to rewrite popular stuff in Rust. This is both inflammatory and wrong. ISRG isn't harassing Stenberg; they're paying him to do the work they want done. And he's not rewriting curl or libcurl in Rust; he's adding optional new backends for key pieces like the HTTP and TLS implementations. https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...
  - oscargrouch 5y ago
    What is inflammatory is the way a part of the Rust community deals with other languages. You are right is not just ISRG, but it is part of this big masonry-like movement forming to replace C++, not by virtue, but by force and politics. Unlike any other language out there that is trying to do it in a clean manner. Android for instance was the last asset with a takeover in this hostile manner, no other language out there ever did before. Despite we have tons of other safe memory languages out there. I cheer for Rust the technology, to grow, but lets care about the language, because its not enough we work so hard to make things work, we still need to feel miserable, no matter the things you have done, because you are not using a pink t-shirt (one vector on a multivector of preferences and goals). Is the end there is much more details into why we choose X and Y. A lot of C and C++ code are out there, and with them a lot of great knowledge. man-years of work, of life into them.. they are wonderful pieces of engineering, and yet, just because they are "not written in the right language ™" it will force by culture and not by virtue that they get kicked off like garbage. This is totally disrespectful, and most of the time is pure marketing and salesman pitch. Rust has yet to prove itself in a lot of fronts, and this will only happen with time. I've seen Daniel being constantly bullied to feel miserable for having its tool in C, in Twitter, in mailing lists.. and he is just a sample..
baybal2 5y ago
It looks to me an another attempt to force feed people Rust at any cost irrespective of the rationale.
- bbarnett 5y ago
  All I keep seeing, is how rust is perfect for everything, will fix everything, should be everywhere, etc, etc. There's gotta be a profit motive involved. There must.
  - geofft 5y ago
    There is absolutely a profit motive involved! The less time you spend dealing with segfaults and inexplicable double-frees because you have no idea where the first free is, the more time you can spend working on features that impact the business's bottom line. The fewer emergency patches you have to deploy, the more uptime you have and the less you spend on the required ops work. The fewer zero-days you suffer, the fewer existential threats to your business. And so forth. None of this would be happening if the market didn't care. I was one of the people who started the Linux kernel modules in Rust project (I'm credited in the announcement), but I started it because I thought it would be fun, and I have a day job that isn't related to Rust at all. So I've spent almost no time on it recently. The corporate sponsors behind this effort are interested in this because they use Linux (and curl and so forth) at a large enough scale where this sort of thing matters. I would guess that, for instance, Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days (see e.g. https://googleprojectzero.blogspot.com/p/0day.html https://googleprojectzero.blogspot.com/p/0day.html). So that's their profit motive, and I'm very happy it exists, because this work is too important to rely on the free time of people like me. (To be abundantly clear: I am not paid by any of the involved organizations, and I had no advance knowledge of this before the public announcement.)
    - pjmlp 5y ago
      > Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days It is going to be very hard to achieve this when iOS is moving into the direction to have 100% of userspace API available to Swift, while Android team forces us to use C and C++ for anything related with real time audio, machine learning and 3D API. Now in Android 12 even Renderscript was replaced with C and C++ alongside Vulkan compute shaders. The kernel can even be 100% Rust, it won't help those of us that are cloning Oboe or Vulkan github repo, dealing with JNI boilerplate, C and C++ toolchain issues on NDK.
Animats 5y ago
On the "critical infrastructure" front, I'd like to see a few "hard nuts" built. Not many. Just a few special purpose boxes, to start: - A BGP server. - A DNS/DNSSEC server. - A WiFi/home network gateway. Those are critical infrastructure. They're self-contained units which talk well-defined protocols. Their functions don't change much. The first two aren't that price-sensitive. They should be verified down to the bare metal. Apply to DARPA or NIST or DHS for funding for such a project. You might get it.
- jaas 5y ago
  Good ideas! We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!
  - tptacek 5y ago
    I get why BGP sounds like a good target, since it's self-contained and high-importance, but I'd assume the most important BGP4 deployments on the Internet aren't in systems that can replace their BGP4 servers with anything that Cisco isn't itself shipping. Lots of people run little `birds` to advise their upstreams, but they're not running full-feed defaultless; they're minimally exposed. I think the win from a community-driven BGP4 project might be small compared to the investment. But you've been thinking about this already, so I'd love to hear about how wrong I am. :)
    - jaas 5y ago
      What you are describing matches my impression of things. It has been on the back burner because even if we had a great memory safe version of, say, openbgpd, I am not sure that would have particularly widespread impact. You are probably right that we would need to convince Cisco and friends to move to memory safe code.
      - tptacek 5y ago
        A Rust or Go DNS server that served as a drop-in replacement for BIND or nsd, on the other hand, is a big win. :)
nneonneo 5y ago
Very tangential, but the very slight angle on the “Memory Safety” highlight threw me for a loop. For a moment I wasn’t sure if it was actually slanted or not until I zoomed way in to confirm the slant. That’s distracting as heck and I can’t think of a good reason to have such a weird highlight…
- tptacek 5y ago
  JFWIW: the guidelines ask us not to write comments like this (CMD-F for "too common to be interesting"). https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ferdowsi 5y ago
Why the push to have RustTLS replace OpenSSL, instead of Go's TLS library (which is mature and widely used?)
- mwcampbell 5y ago
  I would guess because Go, having a garbage collector and green threads, has a heavier runtime than Rust and is therefore harder to embed into programs written primarily in other languages. Can anyone else speak more authoritatively on this?
- Ericson2314 5y ago
  C -> Go FFI is a lot harder. Per their website, they are a big on a modular approach where libraries can be made memory safe concurrently. Languages with non-trivial runtimes like Go or Haskell just don't support that same model. You would want to convert your libraries in a certain order so there is one continuous C vs non-C boundary.
- tptacek 5y ago
  Go's TLS is the right choice if you're working on a project that uses Go. Go is often a good choice if you're rewriting a whole project to be memory-safe. But if you're retaining a lot of your C/C++ code, and trying to surgically replace the attack-surfacey bits with memory-safe code, that's Rust's job, not Go's.
- topspin 5y ago
  This doesn't deserve the downmods; when one assumes good faith all we have here is a straightforward question. Here is the answer; When you wish to provide a library that you intend for use in diverse applications[1] -- and OpenSSL is a excellent example of exactly this case -- you cannot choose a language with a complex runtime. Go has a complex runtime. There is no getting around this; any non-trivial software implemented in Go will require a number of runtime facilities and accommodating that becomes a burden for the library user. Rust has about the same runtime burden as C/C++. It links the same way as C/C++ and imposes the minimum possible burden on the library user. [1] diverse as in essentially all platforms, from microcontrollers to high performance systems at scale, over decades of evolution.
grumblenum 5y ago
I don’t understand this at all. MISRA C, model checkers and theorem provers all exist to provide some of these guarantees that are, to my knowledge, widely recognized in applications where “safety” actually entails life safety. F* is a very modern tool, I think, developed for precisely these use cases. I’m not aware that the rust compiler is proven or even specified. Avoiding its mechanisms for validating use-once memory isn’t even that uncommon, especially in low-level library code. That Google is the man behind the curtain here also comes off as weird since they have not, to my knowledge, standardized their own critical infrastructure on Rust.
- fsociety 5y ago
  MISRA C is just a standard and developing a codebase in it can still result in memory safety issues. Rust has the guarantees built into the compiler, so if it compiles you have a reasonable standard of memory safety.
  - grumblenum 5y ago
    You would have to sanitize your entire dependency tree for unsafe invocations and also demonstrate that valid rust programs do, in fact, guarantee memory safety, which might be invalidated by previous or future compiler versions. That also ignores known soundness holes, compiler errors, and silliness like how rust binaries leak the file structure they were built on. I don’t see why that’s reasonable, but auto industry standards are not reasonable or a language with a garbage collector is not reasonable. The work happening in model checking is really incredible. Project Everest is focused on addressing exactly the same problems, and I don’t think the rust compilers guarantees have undergone nearly the rigor of that of F*.
    - Ericson2314 5y ago
      > language with a garbage collector That is reasonable. Rust is not the only safe option. Re everything else....Rust should be seen as the beginning not the end. All those model checking and other "post-hoc" analyses come with major productivity pitfalls. (Wrestling with some solver that may or may not be happy for spooky reasons is profoundly disheartening compared to wrestling with something elegant and compositional like a type system. Just as there is the ML family of languages and then SML with CakeML, Rust should continue being a fast-moving target where the occasional mistake might happen, but there is academic work revolving around the language which should create a CompCert/CakeML with time. Some aviation/auto software regulation is a legit, but frankly a some of it doubles as regularity ossification the industry secretly like as it creates a mote around existing businesses that have "evolved" compliance from the get-go. In that case, unproductivity is a feature, not a bug. I would not hold it up as a realistic model for these sorts of projects to aspire to. Without drastic changes to the way we found unprofitable FOSS foundation infrastructure, whenever productivity and security are at odds, the former will win over the latter.
jonas21 5y ago
For some reason, the slight tilt to the text "Memory Safety" makes me feel queasy. But I guess maybe that's the point?
ghoward 5y ago
A comment on lobste.rs summed up my feelings perfectly. https://lobste.rs/s/hpk3lu/prossimo_memory_safety_project#c_drr8ho https://lobste.rs/s/hpk3lu/prossimo_memory_safety_project#c_...

130 points by eplanit 5y ago

sometimesshit 5y ago

"Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers."

baybal2 5y ago
That made me laugh. Can people treat such people seriously when they obviously aren't? Dumb, aggressive promotion is characteristic of "trendy hipster projects" usually abandoned once the "cred" harvest is finished, and people involved go on.
- bombela 5y ago
  It's both funny and true at the same time. I used to advertise my worth in how good my C++ is. Until I had a dumb after free error after git merging two adjacent line in the wrong order. A simple vector push done after capturing vector.begin instead of before. Nobody saw that in code review. Even reviews from C++ experts at the company. Of course it took 6 months until the first segfault. Invalidating 6 months of work. Rust would have not compiled. As simple as that. Now imagine if you could write code without living in fear of making everything blow up because of a single moment of weakness. That's Rust for me.
  - saagarjha 5y ago
    > Invalidating 6 months of work. What kind of system was this where a bug would literally invalidate all results from the moment it was introduced?
    - grumblenum 5y ago
      It’s just another of many testimonials of projects that will not be named at companies that will not be disclosed with implausible circumstances or unlikely details here to convince you that you had better switch your tech stack to this brand new thing before you too become a cautionary tale.
      - bombela 5y ago
        Google. Backup of filers. Conversion from NetApp filer dumps to tarball. I did open source a prototype of the tool. I don't know if it has the bug. The final version was to Google standard of C++ and maybe some cleaner abstractions. https://github.com/bombela/dump2tar https://github.com/bombela/dump2tar
- tptacek 5y ago
  These people are obviously serious.
- topspin 5y ago
  It would be funny if they couldn't cite an endless stream of evidence for their argument. They can, however. And it's not going to stop. That's the thing about the memory safety argument; the people making it have an endless supply of ammunition, resupplied daily.
  - opnitro 5y ago
    See: https://twitter.com/LazyFishBarrel https://twitter.com/LazyFishBarrel
dang 5y ago
Please keep unsubstantive comments and flamebait off HN. Programming language flamewars are particularly tedious and particularly avoidable, so please avoid them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

xvilka 5y ago

Finishing Firefox oxidation[1] should become a priority too. Also, combining all separate modern alternatives[2] to coreutils and such in Rust, like exa, dust, etc into one umbrella project. [1] https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation [2] https://github.com/ibraheemdev/modern-unix https://github.com/ibraheemdev/modern-unix

dochtman 5y ago
See also https://github.com/uutils/coreutils/ https://github.com/uutils/coreutils/
nerdponx 5y ago
I love that Rust has become a successful systems language with memory safety. And while I use many of these "coreutils replacements" frequently, they are mostly not equivalent to the originals, and I think it's disingenuous to claim that they are.
- tialaramex 5y ago
  They aren't drop-in replacements, but I think "equivalents" is fair. Your existing bash scripts don't work in an alternate universe where computers come with ripgrep not grep, but that universe isn't very different otherwise. Some things are a little easier to do, some things are a little harder to do, there are different bugs than in our universe, but it's way less strange than a universe where Lisp Machines still dominate, or even one where the Network uses X.25 rather than IP.
- justaj 5y ago
  I think https://github.com/uutils/coreutils https://github.com/uutils/coreutils is aiming to provide drop-in replacements.
Ericson2314 5y ago
Good luck getting Google to fund that one particular go, heh. Even if they do fund Mozilla.

px43 5y ago

Eh, memory safety hasn't ever really been the problem with mod_tls, or curl, but it would be nice to have some solid examples for other projects to build on. The Linux kernel project sounds interesting. It would be nice if there was an effort to purge as much C code as possible from the core of the kernel and really enforce standards such that even a maliciously designed kernel module should not be vulnerable to memory corruption bugs.

deleted 5y ago
[deleted]
topspin 5y ago
Here[1] is the ongoing list of "curl security problems." Note the several memory safety related issues. The two most recent are: May 26, 2021 CWE-416: Use After Free May 26, 2021 CWE-457: Use of Uninitialized Variable There are numerous others that follow including out-of-bounds reads, overflows, etc. I can't imagine where you got the idea that this somehow "hasn't ever really been" a problem for curl. [1] https://curl.se/docs/security.html https://curl.se/docs/security.html
simion314 5y ago
Why not have all this Rust energy focused on a new kernel (not a toy/experiment), a kernel architect ed not evolved. You would get better results and if you need Linux compatibility add support for it from the start in soem kind of emulation/compatibility layer. Putting Rust into kernel seems to me that is a lot of effor for microscopic gains.
- aaomidi 5y ago
  A new kernel has a massive uphill battle to fight to get to where Linux is today. Like, an absolutely huge battle to fight. Although it would be great to eventually see it.
  - simion314 5y ago
    I know, but Linux will not be forever, someone will start a new kernel that will replace it. All this giant tech companies could afford to pay some experienced people to start working on it. The initial scope would be limited but if the architecture and the language combo would give it a performance and security boost then for sure it will be adopted and new contributors would appear. If the performance/security would be similar to Linux/BSD then for sure the progress would be very slow.

deleted 5y ago

[deleted]

oscargrouch 5y ago

TIL: That there's an ORG to effectively harass people like Daniel Stenberg to rewrite popular stuff in Rust. To the Internet Security Research Group just fuck you! you will take my C++ out of my dead cold hands. I've never expected to see fascist ideology to get encoded into language culture. Lets make it even better, why don't we all get back to typewriters giving there will be no more bugs? There is a right way to do it: Do your own cool things in Rust. It will get popular and the language will get there eventually. This is not the right way, as developers are formed over technologies and their knowledge is even more important than the tools. Rust will form developers that will do great things, if C++ is a thing of the past it will get obsolete organically. Please rewrite Linux in Rust if you wish but leave Linus Torvalds alone. I cant wait for the next Rust driver module to freeze my flawless Linux in "dirty" C..

mwcampbell 5y ago
> TIL: That there's an ORG to effectively harass people like Daniel Stenberg to rewrite popular stuff in Rust. This is both inflammatory and wrong. ISRG isn't harassing Stenberg; they're paying him to do the work they want done. And he's not rewriting curl or libcurl in Rust; he's adding optional new backends for key pieces like the HTTP and TLS implementations. https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...
- oscargrouch 5y ago
  What is inflammatory is the way a part of the Rust community deals with other languages. You are right is not just ISRG, but it is part of this big masonry-like movement forming to replace C++, not by virtue, but by force and politics. Unlike any other language out there that is trying to do it in a clean manner. Android for instance was the last asset with a takeover in this hostile manner, no other language out there ever did before. Despite we have tons of other safe memory languages out there. I cheer for Rust the technology, to grow, but lets care about the language, because its not enough we work so hard to make things work, we still need to feel miserable, no matter the things you have done, because you are not using a pink t-shirt (one vector on a multivector of preferences and goals). Is the end there is much more details into why we choose X and Y. A lot of C and C++ code are out there, and with them a lot of great knowledge. man-years of work, of life into them.. they are wonderful pieces of engineering, and yet, just because they are "not written in the right language ™" it will force by culture and not by virtue that they get kicked off like garbage. This is totally disrespectful, and most of the time is pure marketing and salesman pitch. Rust has yet to prove itself in a lot of fronts, and this will only happen with time. I've seen Daniel being constantly bullied to feel miserable for having its tool in C, in Twitter, in mailing lists.. and he is just a sample..

baybal2 5y ago

It looks to me an another attempt to force feed people Rust at any cost irrespective of the rationale.

bbarnett 5y ago
All I keep seeing, is how rust is perfect for everything, will fix everything, should be everywhere, etc, etc. There's gotta be a profit motive involved. There must.
- geofft 5y ago
  There is absolutely a profit motive involved! The less time you spend dealing with segfaults and inexplicable double-frees because you have no idea where the first free is, the more time you can spend working on features that impact the business's bottom line. The fewer emergency patches you have to deploy, the more uptime you have and the less you spend on the required ops work. The fewer zero-days you suffer, the fewer existential threats to your business. And so forth. None of this would be happening if the market didn't care. I was one of the people who started the Linux kernel modules in Rust project (I'm credited in the announcement), but I started it because I thought it would be fun, and I have a day job that isn't related to Rust at all. So I've spent almost no time on it recently. The corporate sponsors behind this effort are interested in this because they use Linux (and curl and so forth) at a large enough scale where this sort of thing matters. I would guess that, for instance, Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days (see e.g. https://googleprojectzero.blogspot.com/p/0day.html https://googleprojectzero.blogspot.com/p/0day.html). So that's their profit motive, and I'm very happy it exists, because this work is too important to rely on the free time of people like me. (To be abundantly clear: I am not paid by any of the involved organizations, and I had no advance knowledge of this before the public announcement.)
  - pjmlp 5y ago
    > Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days It is going to be very hard to achieve this when iOS is moving into the direction to have 100% of userspace API available to Swift, while Android team forces us to use C and C++ for anything related with real time audio, machine learning and 3D API. Now in Android 12 even Renderscript was replaced with C and C++ alongside Vulkan compute shaders. The kernel can even be 100% Rust, it won't help those of us that are cloning Oboe or Vulkan github repo, dealing with JNI boilerplate, C and C++ toolchain issues on NDK.

Animats 5y ago

On the "critical infrastructure" front, I'd like to see a few "hard nuts" built. Not many. Just a few special purpose boxes, to start: - A BGP server. - A DNS/DNSSEC server. - A WiFi/home network gateway. Those are critical infrastructure. They're self-contained units which talk well-defined protocols. Their functions don't change much. The first two aren't that price-sensitive. They should be verified down to the bare metal. Apply to DARPA or NIST or DHS for funding for such a project. You might get it.

jaas 5y ago
Good ideas! We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!
- tptacek 5y ago
  I get why BGP sounds like a good target, since it's self-contained and high-importance, but I'd assume the most important BGP4 deployments on the Internet aren't in systems that can replace their BGP4 servers with anything that Cisco isn't itself shipping. Lots of people run little `birds` to advise their upstreams, but they're not running full-feed defaultless; they're minimally exposed. I think the win from a community-driven BGP4 project might be small compared to the investment. But you've been thinking about this already, so I'd love to hear about how wrong I am. :)
  - jaas 5y ago
    What you are describing matches my impression of things. It has been on the back burner because even if we had a great memory safe version of, say, openbgpd, I am not sure that would have particularly widespread impact. You are probably right that we would need to convince Cisco and friends to move to memory safe code.
    - tptacek 5y ago
      A Rust or Go DNS server that served as a drop-in replacement for BIND or nsd, on the other hand, is a big win. :)

nneonneo 5y ago

Very tangential, but the very slight angle on the “Memory Safety” highlight threw me for a loop. For a moment I wasn’t sure if it was actually slanted or not until I zoomed way in to confirm the slant. That’s distracting as heck and I can’t think of a good reason to have such a weird highlight…

tptacek 5y ago
JFWIW: the guidelines ask us not to write comments like this (CMD-F for "too common to be interesting"). https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ferdowsi 5y ago

Why the push to have RustTLS replace OpenSSL, instead of Go's TLS library (which is mature and widely used?)

mwcampbell 5y ago
I would guess because Go, having a garbage collector and green threads, has a heavier runtime than Rust and is therefore harder to embed into programs written primarily in other languages. Can anyone else speak more authoritatively on this?
Ericson2314 5y ago
C -> Go FFI is a lot harder. Per their website, they are a big on a modular approach where libraries can be made memory safe concurrently. Languages with non-trivial runtimes like Go or Haskell just don't support that same model. You would want to convert your libraries in a certain order so there is one continuous C vs non-C boundary.
tptacek 5y ago
Go's TLS is the right choice if you're working on a project that uses Go. Go is often a good choice if you're rewriting a whole project to be memory-safe. But if you're retaining a lot of your C/C++ code, and trying to surgically replace the attack-surfacey bits with memory-safe code, that's Rust's job, not Go's.
topspin 5y ago
This doesn't deserve the downmods; when one assumes good faith all we have here is a straightforward question. Here is the answer; When you wish to provide a library that you intend for use in diverse applications[1] -- and OpenSSL is a excellent example of exactly this case -- you cannot choose a language with a complex runtime. Go has a complex runtime. There is no getting around this; any non-trivial software implemented in Go will require a number of runtime facilities and accommodating that becomes a burden for the library user. Rust has about the same runtime burden as C/C++. It links the same way as C/C++ and imposes the minimum possible burden on the library user. [1] diverse as in essentially all platforms, from microcontrollers to high performance systems at scale, over decades of evolution.

grumblenum 5y ago

I don’t understand this at all. MISRA C, model checkers and theorem provers all exist to provide some of these guarantees that are, to my knowledge, widely recognized in applications where “safety” actually entails life safety. F* is a very modern tool, I think, developed for precisely these use cases. I’m not aware that the rust compiler is proven or even specified. Avoiding its mechanisms for validating use-once memory isn’t even that uncommon, especially in low-level library code. That Google is the man behind the curtain here also comes off as weird since they have not, to my knowledge, standardized their own critical infrastructure on Rust.

fsociety 5y ago
MISRA C is just a standard and developing a codebase in it can still result in memory safety issues. Rust has the guarantees built into the compiler, so if it compiles you have a reasonable standard of memory safety.
- grumblenum 5y ago
  You would have to sanitize your entire dependency tree for unsafe invocations and also demonstrate that valid rust programs do, in fact, guarantee memory safety, which might be invalidated by previous or future compiler versions. That also ignores known soundness holes, compiler errors, and silliness like how rust binaries leak the file structure they were built on. I don’t see why that’s reasonable, but auto industry standards are not reasonable or a language with a garbage collector is not reasonable. The work happening in model checking is really incredible. Project Everest is focused on addressing exactly the same problems, and I don’t think the rust compilers guarantees have undergone nearly the rigor of that of F*.
  - Ericson2314 5y ago
    > language with a garbage collector That is reasonable. Rust is not the only safe option. Re everything else....Rust should be seen as the beginning not the end. All those model checking and other "post-hoc" analyses come with major productivity pitfalls. (Wrestling with some solver that may or may not be happy for spooky reasons is profoundly disheartening compared to wrestling with something elegant and compositional like a type system. Just as there is the ML family of languages and then SML with CakeML, Rust should continue being a fast-moving target where the occasional mistake might happen, but there is academic work revolving around the language which should create a CompCert/CakeML with time. Some aviation/auto software regulation is a legit, but frankly a some of it doubles as regularity ossification the industry secretly like as it creates a mote around existing businesses that have "evolved" compliance from the get-go. In that case, unproductivity is a feature, not a bug. I would not hold it up as a realistic model for these sorts of projects to aspire to. Without drastic changes to the way we found unprofitable FOSS foundation infrastructure, whenever productivity and security are at odds, the former will win over the latter.

jonas21 5y ago

For some reason, the slight tilt to the text "Memory Safety" makes me feel queasy. But I guess maybe that's the point?

ghoward 5y ago

A comment on lobste.rs summed up my feelings perfectly. https://lobste.rs/s/hpk3lu/prossimo_memory_safety_project#c_drr8ho https://lobste.rs/s/hpk3lu/prossimo_memory_safety_project#c_...