5 ms·
I'd love QEMU to move to some safer language. Unfortunately I don't know any which meet the necessary criteria: - support linux, osx, windows - mature enough
by pm215 10y ago
I'd love QEMU to move to some safer language. Unfortunately I don't know any which meet the necessary criteria:
- support linux, osx, windows
- mature enough for widespread support in distros
- support at least half a dozen different host cpu architectures
- simply interoperable at a C ABI level so you can move parts of the system to the new language without doing a 100% rewrite
(There are probably other requirements too but that last one is the biggie really.)
- pjmlp 10y agoAda, FreePascal, ...?
- ludamad 10y agoProblem is that when you use C you get the low level coders on board relatively easily. Not always the case in other languages
- pjmlp 10y agoWhen I started programming, C was just yet another systems programming language. Low level coders were using straight Assembly. I find ironic to see such statements about 40 years later.
- nickpsecurity 10y agoThen Cyclone or any of safe C subsets/variants.
- jjnoakes 10y agoCyclone is no longer active last time I checked. Or is it? What other safe C subsets/variants are out there which are actively being worked on? Cyclone and bit-c interested me greatly so pointers would be appreciated.
- cvwright 10y agoThe author of Cyclone seems to suggest that Rust is the current path forward: http://trevorjim.com/unfrozen-cyclone/ http://trevorjim.com/unfrozen-cyclone/ > Cyclone was an early attempt to create a programming language at the level of C, combining manual memory management with complete static memory safety. You can think of it as one step on the path that Rust and other languages have continued, one that I believe will eventually replace C, eliminating a host of severe security problems.
- nickpsecurity 10y agoCyclone, particularly its memory management, was one of the inspirations for Rust. That said, there's no way in hell Rust is a C replacement for people sold on C itself. There's people that need safe, fast, systems code. Rust can probably handle that. Then, there's people that think C is best language or don't want to learn something too different. They're not switching to Rust under any circumstances. The safer C's are useful for those people. Still have to force or pay them to do it as the C zeal is so strong. Yet, the smaller the adjustment, the more likely the uptake. Worked for C and Java vs others that clean-slated things.
- nickpsecurity 10y agoIt's not. Like most of academic ones, it can be picked up or clean-slated if people really want it. The authors tend to move on, though, as in BitC (unfortunately...). I have some others for you, though. Most research is on automatically transforming C instead of a safer, manually-done C. Best are these: https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://sva.cs.illinois.edu/downloads.html http://sva.cs.illinois.edu/downloads.html http://dslab.epfl.ch/proj/cpi/ http://dslab.epfl.ch/proj/cpi/ Paper mentioning several of the safe C's, including those like Vault you can't have: https://pdfs.semanticscholar.org/a890/a850dc78e65e26f8f4def435b17094ce08cf.pdf https://pdfs.semanticscholar.org/a890/a850dc78e65e26f8f4def4... Galois, as usual, graciously open-sourced two of theirs (Ivory & Tower) that's already fielded in real world: http://ivorylang.org/ http://ivorylang.org/ Popcorn and TALC are older ones in prototype form: https://www.cs.cornell.edu/talc/releases.html https://www.cs.cornell.edu/talc/releases.html Someone here showed me this one I haven't evaluated but is used in compiler front-end: https://eigenstate.org/myrddin/ https://eigenstate.org/myrddin/ The C0 one used in Verisoft is embedded in vc0compiler-trunk probably. They did great things with it but I haven't been brave enough to try to retrieve it ;). http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html So, altogether, what remains is quite scattered and prototype form. Plus, you still have to rewrite the software. So, I've mostly been recommending people apply Softbound, SAFECode, and CPI to their code just to see what happens. If it still works and fast enough, then just use it as it covers most bases. Also, contributing to those three's codebase is a very, wise move with potentially large impact.
- JoshTriplett 10y agoI have a long-term experiment to implement KVM in Rust. Adding union support to Rust was the first step: https://github.com/rust-lang/rfcs/pull/1444 https://github.com/rust-lang/rfcs/pull/1444
- wyldfire 10y agoHey, great idea. I'm still a bit of a Rust newb but I'm interested in helping if you have a starting point. Otherwise, I'll start looking into it myself.
- JoshTriplett 10y agoThe /dev/kvm API has a hard dependency on union support, and rustc hasn't yet implemented RFC1444, so I hadn't planned to attempt to create a KVM crate until that point. Once that happens, I'll start building prototypes and pushing them to github and Cargo. In the meantime, here's an article I wrote on the /dev/kvm API, including how to drive it directly from a small C program: https://lwn.net/Articles/658511/ https://lwn.net/Articles/658511/ (edit: fixed URL)
- wyldfire 10y agoI think you meant to link to https://lwn.net/Articles/658511/ https://lwn.net/Articles/658511/ Why can't we just alias the storage to something different underneath? How is there a "hard" requirement? Unless it's difficult/impossible to make the representation align correctly without the same semantics?
- JoshTriplett 10y agoThe main data structure for /dev/kvm is `struct kvm_run`, which includes a massive union. There are also unions spread out across the rest of the API; half the structures in the API have some kind of union in them. It would be possible to make that work using unsafe operations like `std::mem::transmute` and careful manual pointer offsets, but that would eliminate much of the benefit of doing this in Rust in the first place.
- GregBuchholz 10y agoSounds like common lisp might be what you are looking for then (depending on what you think "interoperable at a C ABI level" exactly entails I suppose. https://common-lisp.net/project/ecl/main.html https://common-lisp.net/project/ecl/main.html)
- pcwalton 10y agoWhich of these is Rust missing? (Though I should caution that it's not as simple as "just write in a safe language" if you're doing the tricks that QEMU does for speed. That's not to say we shouldn't be moving away from C and C++ in general, however--we should.)
- dijit 10y agolast time I deployed a compiler to a machine in a reliable way it took 45 minutes and a lot of document reading. Rust is not ready for linux yet. (no, `curl -sSf https://static.rust-lang.org/rustup.sh https://static.rust-lang.org/rustup.sh | sh` does not count)
- steveklabnik 10y agoSeveral linuxes have packages in their repositories today, and we're working on fixing the issues for the ones that haven't yet. Firefox now has Rust code in it, so any distro that compiles from source and has Firefox is gonna end up packaging rustc too.
- duaneb 10y agoI dunno, 45 minutes doesn't seem that bad for a manual deployment from scratch including documentation reading. The equivalent with gcc would be days of work.
- pm215 10y agoYeah, Rust is pretty high on the list of candidates, but for instance there is no rust compiler shipped by default in Debian stable, so I don't think it meets "widespread distro support" yet. Also https://doc.rust-lang.org/book/getting-started.html https://doc.rust-lang.org/book/getting-started.html says that everything not x86 is at best only in tier 2 "guaranteed to build", which is not really great on the "support multiple architectures" front; and lack of s390x host support would be a dealbreaker (it's a firmly supported host for running KVM on).
- AnthonyMouse 10y ago> I'd love QEMU to move to some safer language. Unfortunately I don't know any which meet the necessary criteria: - support linux, osx, windows - mature enough for widespread support in distros - support at least half a dozen different host cpu architectures - simply interoperable at a C ABI level so you can move parts of the system to the new language without doing a 100% rewrite There is something to be said for replacing C and old C++ code with C++11 and the safer new constructs like std::unique_ptr. It doesn't stop you from doing unsafe things but it makes it much easier not to, without requiring a complete rewrite.
- JoshTriplett 10y agoThere's a big difference between "easy to use" and "hard to misuse". The problem with C++11 or C++14 is that, for all their additional features, you're still just one cast away from a bug like this.
- pcwalton 10y agounique_ptr isn't safe, and it doesn't provide any safety that you didn't have with smart pointers in earlier versions of C++. In fact, I'm even skeptical of the claim that unique_ptr provides significant security benefits over malloc and free. Leaks aren't the kinds of security problems we're talking about here.
- telos 10y agoThis isn't true - unique_ptr provides protection against Use after Free which is one of the most common memory corruption vulnerabilities in modern applications.
- pcwalton 10y agoNo, it doesn't. There are many ways to get use after free using unique_ptr combined with references or this pointers.
- RotsiserMho 10y ago