6 ms·

In the future, new low-level projects will probably use languages that make it easier to write safe programs, like Rust, Zig, perhaps new languages -- each acco

• sai_c 6y ago
  The problem is most developers and/or management don't care about security. They only care about being done as fast and/or as cheaply as possible. I'm still not convinced the new languages (Rust & Zig) will change the overall situation. Why? Simple example in Rust: "LOL! I need to get stuff done." unsafe { Really nasty hacks here to circumvent any obstacles. } Example in Zig: "LOL! I need to get stuff done. Tests? What tests???" zig build-exe example.zig -O ReleaseFast Trying to solve those security bugs with the help of the language is of course the low hanging fruit. But systems languages will always need an escape hatch for certain problems to be solved. And those mechanisms WILL be abused in the name of "get it done already". So we really need other means to erase those bug classes. Which ones I don't know.
  • rmrfrmrf 6y ago
    In an iterative development process, it's not the end of the world to get potentially unsafe code out the door and then make it safe later, and there's a huge benefit in having unsafe code labeled and framed in source when security bugs are found.
  • pron 6y ago
    We haven't yet solved the problem of how to most effectively reduce such issues in projects where developers and management do care about security (and there are certainly more now that companies can be heavily fined for data breaches), so let's tackle that one first.
  • neysofu 6y ago
    > Trying to solve those security bugs with the help of the language is of course the low hanging fruit. I'm not sure I follow, it seems to me like it's actually a freaking high-hanging fruit. The amount of engineering and design that goes into creating a safe, fast, low-level programming language (i.e. Rust in this case) is enormous and it requires huge amounts of upfront investment. The only reason the industry has largely resorted to unsafe languages is because there's many other lower-hanging fruits, e.g. fuzzing, rigorous unit testing, static analysis tools. These help immensely but at the end of the day only take you so far.
  • skocznymroczny 6y ago
    Yes, most developers and management don't care about security, that's why it's important to bake the security into the language. Unsafe blocks are inconvenient and stand out, so their usage will be limited, while the remaining code will be safe. 90% safe code and 10% unsafe code is much safer than 100% unsafe code.
    • yabudemada 6y ago
      Honestly, just let them have a buffer-overflow. That's what we call "junk food" software and if they are negligent, let them fail.
  • stjohnswarts 6y ago
    This is a problem you can't fix 100%, it has to be taught through catastrophic failure unfortunately. It's a human flaw, rust (et. al.) gives a pathway forward after that.
  • ymbeld 6y ago
    This comment is as low-effort as the hypothetical examples. Will they do things in that way? Heck, let’s just ask: are they doing things in those ways? crickets Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.
  • anewhnaccount2 6y ago
    If you just need to get stuff done in Rust you can just start wrapping things in Rc<>, Arc<>, Box<> or even Gc<>, which introduces runtime overhead on the level of Java. It's safe and allows you to work around thinking about ownership which I think is the main pain-point of using Rust versus other languages. Obviously later if it performance becomes critical you can refactor.
• zozbot234 6y ago
  > They do require a significant effort to use, but it is significantly less effort than a rewrite in another language I do not believe this. Most C code by far is not written in a way that makes it easy to formally guarantee memory safety, so the lowest effort path will necessarily involve refactoring it until it does. And that means that rewriting it altogether into a new language has very few drawbacks, and some additional benefits.
  • pron 6y ago
    > so the lowest effort path will necessarily involve refactoring it until it does. And that means that rewriting it altogether into a new language has very few drawbacks, and some additional benefits. No, because while some refactoring is necessary, it is virtually always local. E.g. if the sound checker can't prove that an access is within an arrays bounds, adding a dynamic test just before it (assuming you don't want to add annotations to help the checker) will make it provable. Rewriting in a new language is certainly one way to reduce or eliminate memory errors, but if your goal is to reduce or eliminate memory errors in existing codebases, there are other ways that are cheaper, more proven, less risky and are applicable to more environments. These tools are already much more heavily used in safety- and security-critical codebases than any new language, so people are slowly getting good experience with them.
    • mlindner 6y ago
      I’m not sure what C code bases you’ve worked with but refactoring in a large C code base is almost never local. Especially if it’s a code base that made extensive use of the gcc flags that disable making sure code does not alias.
      • pron 6y ago
        Providing enough information for the prover does not require a big refactoring, and is significantly cheaper and less risky than a rewrite for an established codebase.
  • egeozcan 6y ago
• xurukefi 6y ago
  I'm a bit hesitant to believe that in the future low level systems programming will be done using languages like Rust, Nim or Zig. I would really love to see that but the programmers I know in that area are very reluctant to accept any additional layer between them and the hardware. It's not even just low level systems programming, but basically any large project with some sort of performance constraints still seems to stick to C++.
  • neysofu 6y ago
    Nim is inherently higher-level compared to C, so I understand your point. But how does e.g. Rust or Zig interpose additional layers between the programmer and the hardware? It's not like they introduce complicated runtimes or have expensive FFI. Rust in particular is receiving lots of interest for security-conscious and/or performance-critical projects (browsers, operating systems, cryptography, container technologies, HFT-related stuff). I think that speaks volumes as to Rust's capabilities in this area.
  • CodeArtisan 6y ago
    Linus Torlvads on why C and not something else (2012) https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s
  • pjmlp 6y ago
    C´s success is an effect of UNIX's adoption. Outside Bell Labs, operating systems were being written in safer systems programming languages, and one of the reasons why Unisys still has enough customers that care to pay for ClearPath MCP, which has a security level no UNIX clone is capable of, thanks NEWP.
  • tene 6y ago
    Could you explain what additional layer is between me and the hardware when using Rust vs using C? I've written a lot of Rust, and a lot of C, and I can't figure out what you're referring to here.
  • ymbeld 6y ago
    All the layers that I see Rust and Zig are introducing have to do with the compiler. And if advanced compilation is a “layer” then Mr. zero-cost-abstractions C++ shouldn’t throw stones.
• yabudemada 6y ago
  I second this: it's because C is a simple language. Modern languages are a cluster-f*k of features and there are still opportunities to code in security holes. Frankly, if you were to boil down the "unsafe" C vulnerabilities it is a small class of exploits, suitable for automated detection. The interesting thing about C is that it is one of the few languages which has been able to survive without massive changes throughout the years. All these hyped-up modern languages are in flux ALL THE TIME.
  • ymbeld 6y ago
    > Frankly, if you were to boil down the "unsafe" C vulnerabilities it is a small class of exploits, suitable for automated detection. Ah, it’s simple, then. We will await eagerly for the non-forthcoming links to all those efforts/implementations. Or would you like to walk that back to “in principle suitable for automated detection”?
    • pron 6y ago
      It is certainly not simple, and while there's a limit to what languages can do to assist correctness, C sets a particularly low bar, one that newer low-level languages like Zig and Rust can and do improve upon. Having said that, eliminating memory errors from C is not only doable in principle, but used in practice, so far more than new low-level languages (see, e.g. https://trust-in-soft.com/ https://trust-in-soft.com/). It does take a fair deal of work, but for established codebases, the approach is cheaper, less risky and better established than new languages.
• ksec 6y ago
  Zig is probably closest to C for the target audience. Although I wouldn't mind if Pascal or Ada swings back to mainstream's attention.