8 ms·

Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Exploits like this come up all the time, and we

• hendzen 11y ago
  So are you personally volunteering to rewrite all of Linux and glibc in Rust? Are you or your employer volunteering to fund such efforts? There is a reason it hasn't happened yet - because doing so would be exceptionally time consuming and expensive.
  • golergka 11y ago
    Right now, companies that run linux on their servers don't have to pay huge fines when security meltdowns happen. I imagine if they would, they would put more money into the problem: either fund linux development or created more of a market for commercial server operating systems (which can still be open source, at least in some interpretations of the term), for example.
    • nitrogen 11y ago
      No. Strict liability for third party software failure is not a good idea. Software gains much much more from the freedom to innovate than it loses from exploits. Strict liability would be a terrible blow against basically everything HN represents.
      • golergka 11y ago
        Well, there are areas where freedom to innovate is more important, and then there are areas where liability is more important. May be US (as de-facto main government-level actor in IT and internet) could create voluntary certification that opened up companies to such liabilities? Small startup operating from a garage — no certification necessary, but users are aware that no one is guaranteeing anything. IBM? Level A certification which they advertise everywhere, with billions of dollars in potential fines.
        • ivl 11y ago
          If it was voluntary, I doubt many of those companies would see it as worth the risk. The problem is that these errors happen because so many people are working on interdependent parts. Many times, it's not even your error that can make your software vulnerable. I dislike making anything so risky, because we'll see much, much less good software at the end of the day.
          • ptaipale 11y ago
            Plus a culture of risk-avoidance, blame-shifting and bureaucracy-over-innovation. I even feel the breath of having Ada (the language) enforced over all of us again, and similar ideas... (Not that Ada is so bad as a language, it's more about the ideas of enforcement and top-down control...)
  • efuquen 11y ago
    I think OP isn't naively assuming it would be easy, or any one person would do it. More the point is there probably isn't enough of an effort or emphasis on the Linux/OSS communities part to even attempt it.
  • deleted 11y ago
    [deleted]
• mbreedlove 11y ago
  "It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
  • jimktrains2 11y ago
    Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.
    • deleted 11y ago
      [deleted]
    • qznc 11y ago
      Rust also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide. (For my projects I prefer D, but Rust has a point here)
      • nyan4 11y ago
        Nim GC is optional; It can be disabled to write system libraries.
    • deleted 11y ago
      [deleted]
    • denim_chicken 11y ago
      Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.
      • ufo 11y ago
• cmrx64 11y ago
  I'm happy to have more contributors! ;) https://robigalia.org/ https://robigalia.org/
• efuquen 11y ago
  https://github.com/redox-os/redox https://github.com/redox-os/redox https://github.com/uutils/coreutils https://github.com/uutils/coreutils
• laumars 11y ago
  "memory safe" languages aren't a silver bullet and urgently rewriting core libraries in a new language can be more dangerous than our current process of analyzing and fixing the existing vulnerabilities in our current libraries. However I'm all for experimental research projects developing alternative solutions.
  • marcosdumay 11y ago
    Of course, there's no silver bullet. But this is yet another bug that could not exist at all in a language with automatic memory management. And there are lots and lots of those bugs.
    • laumars 11y ago
      Indeed. But my point was there's lots and lots of ways code can have bugs. Vulnerabilities like these are serious, but rushing through a reimplementation in another language is bound to fail in a multitude of other ways. What we need is not to have knee-jerk reactions akin to angry mops carrying flaming torches and sharpened pitchforks. What we need is to praise the excellent work researchers are doing and to offer our time and/or money into: a) more security research, b) development of experimental alternatives written in memory safe languages, c) yet more security research except this time on the experimental counterparts, d) thorough testing of the experimental counterparts to ensure functional compatibility. Maybe a few years down the line we will have something usable in a few bleeding edge Linux distributions, but it will be even longer still before it will have the backing of Debian, RHEL and SLES.
• thrownaway2424 11y ago
  Your comment was inevitable, but can you also include the options of rewriting in any reasonable form? I'd settle for c++ or even readable c. The problem with this code isn't necessarily the language, it's that it is an unreadable, unreviewable mess.
• sargun 11y ago
  I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optimization. I also think that when writing C, and C++ it makes a lot of sense to restrict oneself as much as possible a la the kinds of standards in the Google Style Guide, or NASA's style guide. Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle.
  • pjmlp 11y ago
    Sometimes there isn't any other choice. For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs. In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs. There are other options, but they are either commercial (e.g. Xamarin), or require lots of DYI hacking with the SDKs toolchains. So if you want to remain productive and not pay for the commercial solutions, there aren't any other alternatives. Which means, even I with my safety rants, end up using them for my mobile OS hobby coding. However if I would be doing this commercially, Xamarin would be my first option.
    • tosseraccount 11y ago
      Isn't slapping C onto objective C trivial for iOS and OSX? Just wrap to the GUI's objective C. You can use this trick for WTL on Window's C++, too.
      • jsmthrowaway 11y ago
        People seem to forget that Objective C is a superset of C. No slapping on required. You're already writing it. Avoid brackets and a few other things and it's C. You don't even have to rename .m to .c, but you can.
• peterwwillis 11y ago
  It's not urgently necessary since all modern systems have some form of simple address space randomization at prelink or exec. Considering the time and effort it would take to safely and completely replace glibc with a new implementation, and the limited scope of its effect on Internet-wide security, it would be more productive to require the kernel itself to support patches like PaX, Exec Shield, or grsec in general, so that all applications (not just ones made with a specific language) would have stack-smashing protection.
  • lmm 11y ago
    None of those things is reliable. They make it harder to exploit this kind of vulnerability, but not impossible; usually they just add one extra required step to the exploitation.
    • peterwwillis 11y ago
      Yes. It's called a mitigation, and it's what we do to make systems more secure. But they certainly can be reliable. The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes reach a broader number of use cases with less effort, and so we get along okay. Likewise, we know that no matter what language we use, there will be at some point a problem with regard to accessing memory, and so we put protections in place to limit the scope of those attacks in a broad sense. It's a more effective mitigation for a greater number of use cases. It is not a panacea.
      • lmm 11y ago
        I find that a lot of security vulnerabilities result from confusion about what side of a security boundary something is on. Treating a parameter as sorta-untrusted can be actively harmful if it leads someone to believe that parameter was supposed to be untrusted. I think it's much more effective to concentrate on strict, designed security boundaries that stop 100% of attacks than to create a bunch of ad-hoc 80% barriers.
• pjmlp 11y ago
  Apparently until the UNIX culture that worships C exist, it won't happen. C only became a thing in computing after UNIX workstations became popular. Before it, there were quite a few safer systems programming languages to choose from, that got steam rolled by C adoption in OS SDKs. Due to its relation with UNIX, it will most likely happen with Apple (Swift), Microsoft (.NET Native, System C#, C++/GSL), Google (Java FTW on Android, Go) than any other OS vendor. But I am also looking forward any of them pick D, Rust, <whatever safe lang> in the process.
  • IgorPartola 11y ago
    > Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html http://developer.android.com/tools/sdk/ndk/index.html
    • pjmlp 11y ago
      Yes and I use it. I also feel the pains that Android teams imposes on the NDK users to use it as little as possible. If you bothered to read the contents of the link that you pushed. "Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need" Also Android Java is nowadays AOT compiled to native code. So whatever C and C++ dependencies there are, could certainly eventually be replaced if there were willingness to do so. Besides, have you ever tried to implement libc in ANSI C, without language extensions and a sprinkle of Assembly?
      • IgorPartola 11y ago
        Nonetheless, it's something that is available to you as a developer. I am firmly in the "right tool for the job" camp, and I can see situations where C is the better tool. I don't see why mobile app development would benefit from it, but I almost never have the opportunity to work with Android. I have never attempted to put together a full libc in ANSI C, no. My experience there is limited to putting together parts of it for various microcontrollers, where I was more or less bound to ANSI C and chose to use no assembly. That's a long way of saying, what's your point? And why do you feel the need to get personal?
• pdonis 11y ago
  > Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Why do "we" have to agree? If somebody really believes this is necessary, why don't they just do it?
  • lawnchair_larry 11y ago
    Sounds like a lot of work. I'd rather just agree.
  • caf 11y ago
    Exactly right. The best vote you can cast for this - and the only one that matters - is to go out and rewrite something.