5 ms·

> When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. So there existe

> When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. So there existed known guest-exploitable vulnerabilities as recently as 8 years ago. Maybe that, combined with the fact that QEMU is not written in Rust, is what is causing Oxide to decide against QEMU. I think it's fair to say that any sufficiently large codebase originally written in C or C++ has memory safety bugs. Yes, the Oxide RFD author may be phrasing this using weasel words; and memory safety bugs may not be exploitable at a given point in a codebase's history. But I don't think that makes Oxide's decision invalid.

bonzini 2y ago
That would be a damn good record though, isn't it? (I am fairly sure that more were found since, but the point is that these are pretty rare). Firecracker, which is written in Rust, had one in 2019: https://www.cve.org/CVERecord?id=CVE-2019-18960 https://www.cve.org/CVERecord?id=CVE-2019-18960 Also QEMU's fuzzing is very sophisticated. Most recent vulnerabilities were found that way rather than by security researchers, which I don't think it's the case for "competitors".
- TimTheTinker 2y ago
  You're not wrong, and that is very impressive. There's nothing like well-applied fuzzing to improve security. But I still don't think that makes Oxide's decision or my comment necessarily invalid, if only because of an a priori decision to stick with Rust system-wide -- it raises the floor on software quality.
  - akira2501 2y ago
    > it raises the floor on software quality. Languages cannot possibly do this.
    - TimTheTinker 2y ago
      I believe TypeScript and Rust are both strong examples of languages that do this (for different reasons and in different ways). It's also possible for a language to raise the ceiling of software quality, and Zig is an excellent example. I'm thinking of "floors" and "ceilings" as the outer bounds of what happens in real, everyday life within particular software ecosystems in terms of software quality. By "quality" I mean all of capabilities, performance, and absence of problems. It takes a team of great engineers (and management willing to take a risk) to benefit from a raised ceiling. TigerBeetle[0] is an example of what happens when you pair a great team, great research, and a high-ceiling language. [0] https://tigerbeetle.com/ https://tigerbeetle.com/
      - akira2501 2y ago
        > possible for a language to raise the ceiling of software quality Cargo is widely recognized as low quality. The thesis fails within it's own standard packaging. It's possible for a language to be used by _more people_ and thus raise the quality _in aggregate_ of produced software but the language itself has no bearing on quality in any objective measure. > to benefit from a raised ceiling You're explicitly putting the cart before the horse here. The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool. Acolytes are uncomfortable saying this because it also destroys the negative case, which is, it would be impossible to write quality software in a previous generation language. > TigerBeetle[0] is an example Of a protocol and a particular implementation of that protocol. It has client libraries in multiple languages. This has no bearing on this point.
        TimTheTinker 2y ago
        > The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool. That's totally true, and I never contradicted that. By "ceiling" I mean the limit of what is possible. A great team can do a lot more when they have great tools.
        sophacles 2y ago
  - cLe223 2y ago
    1. Oxide made an unproven statement ("QEMU is often the subject of bugs affecting its reliability and security.") 2. OP (bonzini) has given specific and valid arguments that that statement is wrong. 3. You're not answering to that specific arguments, but defending Rust and bashing C++ generally without giving any prove. 4. bonzini again provides specific arguments that your generalization is not correct in that context. That despite Firecracker being written in Rust it had a security issue. 5. You still insist without given any solid argument. You just insist that Rust is superior. Not helpful in any discussion. Think about it.
    - TimTheTinker 2y ago
      You're right on (1) and (2) - Oxide used weasel words when explaining the decision. My point is that their poor explanation doesn't necessarily mean it was the wrong decision. A bad defense attorney doesn't imply the defendant committed the crime. I'm not bashing C++ beyond saying "any sufficiently large codebase originally written in C or C++ has memory safety bugs". I did not say those bugs are exploitable, just that they're present. I'm also not insisting Rust is superior, except to say that it raises the floor of software quality, because it nearly eliminates a class of memory safety bugs. Do you disagree? Neither of those statements implies C++ sucks or that Rust is awesome. Just 2 important data points (among many others) to consider in whatever context you're writing code in.
- otabdeveloper4 2y ago
  [flagged]
  - ameliaquining 2y ago
    I do think that only having one CVE in six years is a pretty decent record, especially since that vulnerability probably didn't grant arbitrary code execution in practice. Rust is an important part of how Firecracker pulls this off, but it's not the only part. Another important part is that it's a much smaller codebase than QEMU, so there are fewer places for bugs to hide. (This, in turn, is possible in part because Firecracker deliberately doesn't implement any features that aren't necessary for its core use case of server-side workload isolation, whereas QEMU aims to be usable for anything that you might want to use a VM for.)
  - sophacles 2y ago
    Why is it the only people who say this at all are people saying it sarcastically or quoting fictional strawmen (and can never seem to provide evidence of it being said in earnest)?
    - otabdeveloper4 2y ago
      Grandparent comment said it in earnest, do keep up.

bonzini 2y ago

That would be a damn good record though, isn't it? (I am fairly sure that more were found since, but the point is that these are pretty rare). Firecracker, which is written in Rust, had one in 2019: https://www.cve.org/CVERecord?id=CVE-2019-18960 https://www.cve.org/CVERecord?id=CVE-2019-18960 Also QEMU's fuzzing is very sophisticated. Most recent vulnerabilities were found that way rather than by security researchers, which I don't think it's the case for "competitors".

TimTheTinker 2y ago
You're not wrong, and that is very impressive. There's nothing like well-applied fuzzing to improve security. But I still don't think that makes Oxide's decision or my comment necessarily invalid, if only because of an a priori decision to stick with Rust system-wide -- it raises the floor on software quality.
- akira2501 2y ago
  > it raises the floor on software quality. Languages cannot possibly do this.
  - TimTheTinker 2y ago
    I believe TypeScript and Rust are both strong examples of languages that do this (for different reasons and in different ways). It's also possible for a language to raise the ceiling of software quality, and Zig is an excellent example. I'm thinking of "floors" and "ceilings" as the outer bounds of what happens in real, everyday life within particular software ecosystems in terms of software quality. By "quality" I mean all of capabilities, performance, and absence of problems. It takes a team of great engineers (and management willing to take a risk) to benefit from a raised ceiling. TigerBeetle[0] is an example of what happens when you pair a great team, great research, and a high-ceiling language. [0] https://tigerbeetle.com/ https://tigerbeetle.com/
    - akira2501 2y ago
      > possible for a language to raise the ceiling of software quality Cargo is widely recognized as low quality. The thesis fails within it's own standard packaging. It's possible for a language to be used by _more people_ and thus raise the quality _in aggregate_ of produced software but the language itself has no bearing on quality in any objective measure. > to benefit from a raised ceiling You're explicitly putting the cart before the horse here. The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool. Acolytes are uncomfortable saying this because it also destroys the negative case, which is, it would be impossible to write quality software in a previous generation language. > TigerBeetle[0] is an example Of a protocol and a particular implementation of that protocol. It has client libraries in multiple languages. This has no bearing on this point.
      - TimTheTinker 2y ago
        > The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool. That's totally true, and I never contradicted that. By "ceiling" I mean the limit of what is possible. A great team can do a lot more when they have great tools.
      - sophacles 2y ago
- cLe223 2y ago
  1. Oxide made an unproven statement ("QEMU is often the subject of bugs affecting its reliability and security.") 2. OP (bonzini) has given specific and valid arguments that that statement is wrong. 3. You're not answering to that specific arguments, but defending Rust and bashing C++ generally without giving any prove. 4. bonzini again provides specific arguments that your generalization is not correct in that context. That despite Firecracker being written in Rust it had a security issue. 5. You still insist without given any solid argument. You just insist that Rust is superior. Not helpful in any discussion. Think about it.
  - TimTheTinker 2y ago
    You're right on (1) and (2) - Oxide used weasel words when explaining the decision. My point is that their poor explanation doesn't necessarily mean it was the wrong decision. A bad defense attorney doesn't imply the defendant committed the crime. I'm not bashing C++ beyond saying "any sufficiently large codebase originally written in C or C++ has memory safety bugs". I did not say those bugs are exploitable, just that they're present. I'm also not insisting Rust is superior, except to say that it raises the floor of software quality, because it nearly eliminates a class of memory safety bugs. Do you disagree? Neither of those statements implies C++ sucks or that Rust is awesome. Just 2 important data points (among many others) to consider in whatever context you're writing code in.
otabdeveloper4 2y ago
[flagged]
- ameliaquining 2y ago
  I do think that only having one CVE in six years is a pretty decent record, especially since that vulnerability probably didn't grant arbitrary code execution in practice. Rust is an important part of how Firecracker pulls this off, but it's not the only part. Another important part is that it's a much smaller codebase than QEMU, so there are fewer places for bugs to hide. (This, in turn, is possible in part because Firecracker deliberately doesn't implement any features that aren't necessary for its core use case of server-side workload isolation, whereas QEMU aims to be usable for anything that you might want to use a VM for.)
- sophacles 2y ago
  Why is it the only people who say this at all are people saying it sarcastically or quoting fictional strawmen (and can never seem to provide evidence of it being said in earnest)?
  - otabdeveloper4 2y ago
    Grandparent comment said it in earnest, do keep up.