7 ms·

We really need to stop writing network code in unsafe languages, period.

• djjaxe 13y ago
  Speed or security?... Age old question.
  • ibotty 13y ago
    no. read the article.
    • djjaxe 13y ago
      I read the article is does not mention speed, performance once, in which it had nothing to do with what I stated. I was simply stating that higher level languages will cause the library to be slower also less easy to be used by other high level languages like python.
      • spc476 13y ago
        The author has several articles about ATS (http://bluishcoder.co.nz/tags/ats/ http://bluishcoder.co.nz/tags/ats/) and from what I've read, it outputs C code that is proven (for the parts that are in ATS) to be correct. There's a bit more detail in "Safer handling of C memory in ATS" (http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memo...) and the end of the article contains some generated C code.
      • slight 13y ago
        I think you should read the article again. The language in question isn't higher level really it just has compile time type checking, which has no overhead.
        • djjaxe 13y ago
          That's still not my point. At the time of starting openssl I don't believe that ATS was around. In any case my point is that back then C lang was the best choice for performance and still is revered as the "fastest" as `nearly` all other languages are written on top of it either directly or indirectly. In any case I would love to see someone tell all of the openssl community to just drop C and switch to a different language.
          • danieldk 13y ago
            C being loved in the UNIX community is one of the primary reasons that these libraries are in C. Ada has been around since the beginning of the eighties, has and had performance that is near that of C, does not use a garbage collector, provides C linkage, and is far more safe than C. If you do allow garbage collection, there were many performant and safe alternatives in the 90ies, such as ML. It's culture as much as performance.
            • djjaxe 13y ago
              Ada is a higher language weather or not it has linkage to C or not. The UNIX community cares about performance, performance, performance.
              • Dewie 13y ago
                'Higher level' doesn't necessarily say anything. Rust and ATS are both higher level than C, but they can both do everything that C does. Is Ada less performant than C? I know it has bounds checking, but that can be turned off for "shipped" software. Does it have some features that incur a runtime cost and that can't be disabled?
                • Avshalom 13y ago
                  Ada with all the runtime features left on is slower than comparable quality C. It's faster than most languages though. With all the runtime turned GNAT can/should produce code with in a percent or two as fast as GCC (they share the same backend). And Ada has a thing called SPARK which is a set of compiler checks to formally verify your code so you can provably turn off those runtime features safely. https://en.wikipedia.org/wiki/RavenSPARK https://en.wikipedia.org/wiki/RavenSPARK
      • sitkack 13y ago
        I do not understand why people keep pushing unsafe code when computers keep getting faster and we have more and more headroom (cpu, memory, bandwidth). There is no excuse to keep running unprovable crypto.
        • djjaxe 13y ago
          Maybe because most of the code currently out there being use by the biggest companies in the world still use these "unsafe" languages. & tons of the job market still is in these "unsafe" languages.
  • ohazi 13y ago
    Both! http://rust-lang.org/ http://rust-lang.org/
    • djjaxe 13y ago
      LOL "* In theory. Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."
      • Pacabel 13y ago
        It's a shame to see that comment has been downvoted. That's a quote directly from the bottom-right corner of the Rust website itself! Rust is promising, without a doubt. But it's not yet truly usable in the same sense that C, C++, Java, Python, Haskell, Go and so many other languages are. Maybe it'll start to get to that point once 1.0 is released, once we see at least some language and library stability, and then perhaps some adoption. But that just hasn't happened yet.
        • Dewie 13y ago
          What some one - I think kibwen - has brought up is that early adopters can benefit in the sense that the language design is still in flux. So these early adopters can uncover weaknesses in the design, before they get to the stage where they have to consider backwards compatibility. So although early adopters might not get any useful software out of learning Rust at this stage, they might indirectly improve their future Rust code by having a small influence on the direction of the language.
        • steveklabnik 13y ago
          I downvoted it because "LOL" is not the kind of comment I'd like to see here. The point could have been made in a more substantial way. Like you just did.
          • djjaxe 13y ago
            Wow sorry I can't laugh at something jeez. So, you have never in your life just felt like re-posting a quote off something and just added a little something to it to show the spirit in which it was meant to be. Now you are just being nitpicky and to be honest rude in a sense. I have just joined this community I am trying to fit in and you just come along and see the comment and you "don't like it" because it's short, sweet and too the point. I am laughing at the comment of the programmer of rust for the quote he put on his site and now you have just totally bashed me because you felt it necessary to not like my simplistic comment. Wow.
  • kilburn 13y ago
    If you are speaking about execution speed, you got the idea wrong. From a quote in the article: > If you use the high level typing stuff coding is a lot more work and requires more thinking, [...] (but) you can even hope for better performance than C by elision of run time checks otherwise considered mandatory, due to proof of correctness from the type system. Expect over 50% of your code to be such proofs in critical software and probably 90% of your brain power to go into constructing them rather than just implementing the algorithm. It's a paradigm shift. The idea is to formally prove that the code is not doing unexpected things. The process is relatively simple to understand: First you define the assumptions you make about the program, its execution environment, and the acceptable/expected results of your program. This is known as "formal specification" of the program. It is a critical part. If your specification is wrong, then the whole approach breaks down. However, this part should be much smaller than your whole codebase, and hence you can be extra careful on it. Next, using this specification, you write proofs showing that the code can not do anything unintended (such as accessing a buffer out of its valid range). The compiler goes through this proofs and checks that everything is provably correct (according to the specification). Then it can generate code without runtime checks that you would otherwise probably implement, because it is sure that certain things cannot happen. As a result, the code may end up being actually faster. Although a bit involved, the idea should be pretty intuitive. It is exactly what you are doing in your mind when programming. The main differences are: 1. We humans are pretty comfortable working with inexact and/or incomplete specifications. Then some undefined behavior happens, and our programs bug out. For instance, it is very easy for us to think about the division operator as something that always yields a value, ignoring the "division by zero" edge case. Computers are not, and force you to specify what exactly should happen when you encounter such edge cases. 2. We are also pretty bad at exhaustively checking every possibility, whereas computers excel at it. With the help of human-written proofs, obviously (otherwise verifying a program would involve checking every possible input for it, which is obviously intractable). TL;DR: The tradeoff here is between development and compilation speed versus correctness, which implies improved security and execution speed.
  • Dewie 13y ago
    No. I think that the article clearly shows: execution speed, safety, programmer productivity ← pick any two
    • alkonaut 13y ago
      This isn't a fundamental dilemma like the consistency/scalability dilemma of databases. This is (or was) just a limitation of languages and compilers. The arguments for using C are many but in this case the most common involve the need for low level access (for perf, timing) C is certainly very much suited for some parts of an SSL implementation e.g. when you need absolute deterministic performance to avoid timing attacks etc. (Although performance should certainly be good enough with modern compilers for most languages, and avoiding side-channel attacks by having deterministic execution time is also possible without resorting to C). Using the execution speed as an argument for writing the whole thing in C is just wrong. I haven't heard any good arguments as to why a library such as OpenSSL shouldn't be written in Haskell (or say 98% Haskell and 2% C). Did someone at some point say "There is 2% of the code that is performance critical and/or needs low-level code for cryptographic reasons so I'll write everything including the network code, command line argument parser, world, dog and kitchen sink in C" ?
      • Dewie 13y ago
        > This isn't a fundamental dilemma like the consistency/scalability dilemma of databases. This is (or was) just a limitation of languages and compilers. You're right. Null pointers are a nuisance in some languages, but other languages have shown that you can remove them and still have just as much of an expressive language (and the compiler can still translate pointers that might be "null" to actual null enabled pointers, so no performance cost). Rust might show that a stronger type system can remove certain raw pointer flaws from the language while still retaining both execution speed and programmer productivity. Dependent types might mature to the point that you can use them and gain both execution speed, productivity and safety - time will tell. > Using the execution speed as an argument for writing the >whole thing in C is just wrong. I haven't heard any good >arguments as to why a library such as OpenSSL shouldn't be >written in Haskell (or say 98% Haskell and 2% C). Did someone at some point say "There is 2% of the code that is performance critical and/or needs low-level code for cryptographic reasons so I'll write everything including the network code, command line argument parser, world, dog and kitchen sink in C" ? ... The article makes the argument that, assuming that the whole program needs to be incredibly performant, you can write say 2% of it in verified ATS code, the rest in C-ish ATS code (ie. without proofs). I guess you can also choose to write 2% verified low-level code, and the rest in a more high level ATS - ATS is a functional language with garbage collection and I presume other high level goodies that functional programmers are used to.
  • doublec 13y ago
    The type safety shown in the article doesn't come at a speed cost. The times are erased during code generation. The generated C code is much like hand crafted C but with the safety confirmed via the types.
• eatfish 13y ago
  But even 'safe' languages have unsafe VMs. There is no question that over the years these VMs (or the runtimes) have had equally severe vulnerabilities. The thing that really sets heartbleed apart is not the details of the bug, it's the scale of the 'infection'. OpenSSL is a core dependency of so many distributions and of so many pieces of software. I think we could argue for lots of different solutions (diversity of implementations, safe languages, more tests) and all of them might be good in one way or another but none of them are a silver bullet for any possible bug either. I think the take away is that you need to in a position to upgrade any part of your software stack at a moment's notice not just the obvious top-level (e.g. Rails/Django/Jetty).
  • iopq 13y ago
    Rust allows you to write safe code without a VM. It is statically checked to be memory and concurrency safe.
    • ASneakyFox 13y ago
      Those aren't the only "dangerous" kinds of mistakes a programmer can make though
      • robin_reala 13y ago
        No, but it eliminates a large chunk of the more comment cases.
      • agapos 13y ago
        Just because you can't design the perfect car, it doesn't mean that you should not improve the breaks.
    • eatfish 13y ago
      1. I think a lot of people believe Rust will just type-check any old program and tell you when it has faults. So you can start with a bit of Ruby/C/Python, translate it to Rust and presto, all your bugs are exposed for the world to see. In practice Rust's type checker accepts only a _very_ small subset of correct programs. I've been in a position to write some decent sized Rust code recently and it takes a shift in your mindset to start writing decent Rust code. Even now there are patterns I'm unsure how to model in Rust. Arena allocation is a good example because it was partly the cause of Heartbleed too. Arena allocation in rust seems to require unsafe pointers and unsafe code blocks. You can look at Rust's standard library and see this. 2. The point being that the Rust language exposes unsafe code blocks and pointers. At some point you're going to hit those blocks (if nothing else in 3rd party code) and you're back to square one: You need to trust unsafe code that it is correct. It doesn't matter if that code is a VM or unsafe code. *edited for some legibility.
• Nursie 13y ago
  So we offload the safety to the people that write the runtimes. I understand that that centralises the potential problem area and may make it easier to address... but it still means that someone has to do the 'hard' bits, and if they get it wrong then everyone using the runtime is screwed. Just like what happened here (too many people depending on a single implementation). I don't know about you, but I'm not 100% comfortable with the idea that other, cleverer people will take care of all that for me, so I don't have to worry my pretty little head about the details of what's really going on with the machine. And look at all the JVM vulnerabilities we've seen recently...