6 ms·

I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible cod

• pcwalton 11y ago
  > A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
  • rubiquity 11y ago
    I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? Drawing attention to an unsafe area can help though. As you can see, I'm running around in circles. Just like every discussion about this does. Until an avid Rust user puts their money where their mouth is, we're all just playing Armchair Programmer.
    • pcwalton 11y ago
      I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.
      • bluejekyll 11y ago
        It's true. In my DNS code I have zero unsafe code. Though I did need to add some new unsafe code to the Rust OpenSSL library, but that's really because of the FFI to C. That too would be unnecessary if OpenSSL was rewritten in Rust.
        • sgrove 11y ago
          What about binding to the OCaml implementation at https://nqsb.io/ https://nqsb.io/ ?
          • nostrademons 11y ago
            Wouldn't that require pulling in the OCaml garbage collector? Much of the reason people use glibc or other low-level libraries rather than a managed runtime is so they don't need to link in a managed runtime.
            • sgrove 11y ago
              Good point, I think it would indeed mean pulling in all of OCaml's runtime model.
        • jononor 11y ago
          Does the OpenSSL library allow/plan for an Rust reimplementation (possibly side-by-side for a while) of the C bits? Seems that would be best practice - assuming the goal is make everything safe Rust.
          • bluejekyll 11y ago
            In theory that's just copying the Rust bridge code and using that as the frontend API for a rewrite. So yes it's possible, you "just" need to rewrite the rust-openssl-sys library. I think the hesitation there is that everyone has gotten it beaten into your head that writing new crypto libraries is dangerous. It's probably safer to use a library that has tons of eyes on it, but at some point we should do it.
    • unscaled 11y ago
      OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have. But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections. Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.
      • panic 11y ago
        It's not decades away! Check out https://sel4.systems https://sel4.systems.
        • cmrx64 11y ago
          And, relatedly, https://robigalia.org/ https://robigalia.org/
        • deleted 11y ago
          [deleted]
    • tatterdemalion 11y ago
      > what percentage of a library like glibc would be spent in unsafe blocks? Probably less than you think. What I think the limit is is that there are functions in glibc that present inherently unsafe interfaces. I'm not sure how many but it might be enough that writing libc in Rust is not that helpful.
      • andrewprock 11y ago
        Once you admit unsafe blocks, you admit that Rust is unsafe. The value of porting from one unsafe language to another is probably only marginal.
    • bluejekyll 11y ago
      > an avid Rust user puts their money where their mouth is There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids. I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are all the same borrow rules, and I know I have a bunch of TODOs in the code to go fix things like extra clones. The IDEs, while good, are not on par with other languages yet. Basically it's a lot of work. And I commend the individuals who've paved the way for me with the std library in Rust, but we still have so much more work to do until there is a full OS env like GNU.
      • rubiquity 11y ago
        Your entire post reinforces the idea that in my list of challenges to writing safe software that #1 is far more the issue than #2.
        • bluejekyll 11y ago
          Yes. I'm agreeing that it's hard and takes a lot of energy. But people are doing it.
    • dikaiosune 11y ago
      Re: amount of low level code needing unsafe blocks, its worth checking out this series that documents creating a bare metal kernel in rust that has lots of type safety and uses shockingly little assembly or unsafe: http://os.phil-opp.com/ http://os.phil-opp.com/
      • pjmlp 11y ago
        C created this wrong perception that you need lots unsafe code, due to how it does strings and vectors. In all safe alternatives to C, just like Rust sure you need unsafe at the Assembly FFI level and hardware integration like IO ports and interrupt handling. But everything else can be just plain safe code.
    • nitrogen 11y ago
      If someone wants to pay me to rewrite glibc in Rust, I'd gladly do it, as I'm sure lots of other devs would. It's actually something I've thought about doing as a hobby, but there are a million other hobbies above it on the list.
      • XorNot 11y ago
        What we need is a way to coordinate the effort I suspect. Given we have glibc as a standard interface, a site which matched up function tests with implementations and made it obvious where to jump in could build a decent community.
  • ktRolster 11y ago
    Memory safety problems are the low-hanging fruit of vulnerabilities. A re-write by unskilled programmers will not guarantee the code is safe, because they will introduce many other kinds of vulnerabilities.
    • pcwalton 11y ago
      Nobody is claiming that Rust prevents all security vulnerabilities. The claim is that memory safety problems are severe enough that a rewrite is justified. (Incidentally, there are other classes of vulnerabilities that Rust and/or its libraries heavily mitigate, such as deserialization issues along the lines of the Rails YAML bug.)
    • CyberDildonics 11y ago
      Are we still talking about libc here?
    • vvanders 11y ago
      Part of what makes Rust awesome is it forces correct ownership and architecture.
      • ktRolster 11y ago
        > Part of what makes Rust awesome is it forces correct...architecture. If you believe that, and follow it, then you will end up with a lousy architecture. A correct architecture cannot be designed without knowledge of the problem domain. That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before. There's plenty of insecure Java code out there.
        • Manishearth 11y ago
          I think the parent is talking about architecture around memory, not the entire program design. > if you believe the language will keep you safe safer != safe.
        • 11y ago
  • wspeirs 11y ago
    Agreed, the hope is that the combination of Rust + a rewrite, you'd be in a MUCH better place than where we are now. I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
    • bertr4nd 11y ago
      Speaking only for myself here, but glibc is almost completely unintelligible. I'm not sure if the Linux kernel is as bad, but with glibc anytime I've gone looking for even a trivial function I've regretted it.
    • ajdlinux 11y ago
      A huge chunk of the work going on in the Linux kernel is supporting specific hardware (device drivers, that kind of thing), which doesn't affect glibc and other core userspace things so much. That said, even excluding that, the kernel probably does see more interest and activity than glibc.
  • panic 11y ago
    Yeah, I'm not saying that a rewrite is necessarily a bad idea or that it wouldn't improve things (though writing a drop-in replacement for something like glibc in Rust sounds pretty challenging to me). The situation I'm talking about is the one where no one has an incentive to improve the software day-to-day. If we really want to fix the problem, we should also look at how it got that way.
    • pcwalton 11y ago
      I think most well-funded commercial C software from that vintage isn't any better.
  • rnovak 11y ago
    You mean other than the fact that it's still running on top of a kernel, BIOS, and other firmware that was ALL written in C or Assembly? Yeah, totally safe /s.
    • pjmlp 11y ago
      Historical accident. I used to do systems programming back when the only OS written in C was UNIX. C wasn't the first systems programming language. Burroughs B5500 was written in Algol 68 with zero lines of Assembly. Just one example from many others in the pioneering days of computing. There are other approaches to writing OSes. If UNIX community ever wants to divorce from C there is a way, but there needs to exist a will as well.
• deleted 11y ago
  [deleted]
• justinmk 11y ago
  This is why I personally think the OSS community should be more encouraging of "salary" style funding. There is a loud, poisonous minority of advocates that seem to think that asking for money is just plain evil. That attitude is a material disservice to OSS in general: it makes OSS weaker and less capable, for the sake of some weird puritan reflex. N.B.: I have never and will never ask for, nor accept any income from OSS work: too much shit-flinging and absurd expectations. But as a _user_ I want OSS, for its own sake, to re-evaluate its attitude towards money.
  • wspeirs 11y ago
    Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?
    • d0mine 11y ago
      The issue with is that if you substitute social norms with money; it is hard to return to social norms later I.e., if you start paying; you have to continue paying. Predictably Irrational http://whistlinginthewind.org/2013/01/15/predictably-irrational-chapter-4-the-cost-of-social-norms/ http://whistlinginthewind.org/2013/01/15/predictably-irratio...
      • wspeirs 11y ago
        What's wrong with continuing to pay? All the time companies pay for support for open source software because they want the "insurance" of having someone to call when the $hit hits the fan. You don't want to pay anymore, go back to glibc...
      • chipsy 11y ago
        True of an individual company or business unit and its major tech decisions, but businesses ultimately die. Thus we have a world where Cobol coexists with Node.js - companies saddled with old software never pay for a new system until it's "beyond too late". But a company with a greenfield project can come in and use whatever hot, hyped-up thing is out there, and it usually in their direct interest if it's free, because at that point they probably aren't terribly concerned about software quality.
• mtgx 11y ago
  Maybe 20 years from now it would get into the same situation, but the point is in those 20 years it could be a lot easier to maintain. Also, the whole point of Rust is to eliminate some classes of bugs, which means there would literally be orders of magnitude fewer bugs to deal with. So I don't think that saying there will be bugs in the new libraries, too, is fair criticism. Also, what's clear is that Linus Torvalds' "just don't be stupid and write incorrect code" policy doesn't work. We need to think of security from a design point of view, not rely on your average programmer to write academically perfect code as a security policy.
• yazaddaruvala 11y ago
  Firstly, I want to say I agree with you that these types of projects require more respect and financial incentives. That said, I think its worth noting: Rust fundamentally democratizes systems programming. Rewriting in Rust, increases the contributor pool for these project from some x to some y. Where x is the subset of people in [1, 2, 3, 4, 5] and y is the subset of people in [1, 4]: 1. Who are eager and have time to help 2. Who know manual memory management really well (also diligent enough to use that knowledge appropriately) [Made redundant by compiler] 3. Who can successfully build, link and test C code on multiple platforms [Made trivial by Cargo] 4. Have appropriate domain knowledge 5. Are not afraid to refactor "working code". [Made better through first class testing, the compiler and community mindset] There is also the aspect that experts get a dramatic boost to their productivity, reducing their time needed, and therefore reducing the level of incentives needed.
  • catnaroek 11y ago
    > [Made redundant by the compiler.] The compiler doesn't obviate the need to understand memory management. Anyone who doesn't understand ownership and borrowing will have really hard time getting rustc to accept their code in the first place. What Rust's type checker does is make up for the human inability to be perfectly careful. Even the most diligent programmer will make mistakes or forget something. (This is a fact of life. It can't be fixed with present-day technology.) Relative to C and C++, Rust enlarges the class of “stupid mistakes” that can be detected automatically, and this is always a good thing, no matter how knowledgeable and careful programmers are.
    • Manishearth 11y ago
      We've actually had feedback from some startups using Rust for low level stuff (where their teams comprise mostly of Python/Ruby/JS devs) that Rust teaches systems programming and memory management quite well (since you're forced to work with it), unlike C++.
      • catnaroek 11y ago
        > Rust teaches systems programming and memory management quite well Couldn't agree more. Incidentally, this is also what I dislike so much about C: it does a very poor job of telling the programmer what is wrong with their program. Learning systems programming with C feels (to me, at least) like learning to walk by crawling in the dark.
• stuaxo 11y ago
  Funny, I've just been thinking the same. Originally I thought it was just joe-randoms-query lib I used in project at work. But the last year I had time to look at more desktop bound programming and see that it really is the whole stack.
• castratikron 11y ago
  >We need to have incentives for maintaining this foundational software. It's my opinion that contributing to free software is a public good, and so we should have state-funded employees whose full-time job is to work on this software. I think something like this is already done in places like France and Europe, but to my knowledge the majority of paid-for American contributions to FLOSS comes from corporations.
  • lawpoop 11y ago
    How would we decide what specific projects are actually worked on?
    • nitrogen 11y ago
      How does the NIH decide what research gets funded?
      • elcritch 11y ago
        * Shudders * In recent years the shifts reduction of public funding levels combined with a cultural shift toward emulating business models and proving ROI has, IMHO, stilted creativity, exploration, and the creation of basic fundamental science. An analogous situation would be tons of grant money spent on Rails-like frameworks (because it's 'hot') while fundamental projects like "rewriting a safe glibc" would be deemed lacking in utility.
  • drewm1980 11y ago
    There is a lot of public funding of FLOSS software through universities. Unfortunately, the funding model doesn't work well for big projects or projects lasting more than a few years. A lot of great stuff is developed using public funds and then abandoned when the developer graduates.
• giancarlostoro 11y ago
  > We need to have incentives for maintaining this foundational software. BountySource?[0] I'm not affiliated with them, but they seem to fit that kind of spot from what I've seen so far. [0]: https://www.bountysource.com/ https://www.bountysource.com/
• jeffdavis 11y ago
  There isn't one "real" problem. You are talking about one problem, and rust solves another. I don't see any reason your comment needs to be framed as a contradiction to the OP.
• Riesling 11y ago
  Maybe do both? Rewriting in Rust and increasing incentives. Writing security critical software in c++/c is not the sensible thing to do in my opinion (even though it is the standard right now). Humans in general cannot handle it without making a lot critical errors. And the people working on those projects are already really smart in general. This has been shown again and again. If c++ was a car, it would force you to place your foot in a special position in between breaking and accelerating. If you do it wrong, your foot will get squashed in the exposed drive train. Of course for the point of the argument I am exaggerating, but I really applaud the efforts Rust has made in order to advance the security of software.