Hacker News Reader

Comment by pm215 | Hacker News Reader

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.)

View on HN

I 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

Hey, 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.

The /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/ (edit: fixed URL)

I think you meant to link to 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?

The 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.

Which 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.)

last 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 | sh` does not count)

I 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.

Several 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.

Yeah, 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 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).

> 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.

There'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.

unique_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.

This isn't true - unique_ptr provides protection against Use after Free which is one of the most common memory corruption vulnerabilities in modern applications.

No, it doesn't. There are many ways to get use after free using unique_ptr combined with references or this pointers.

Protection != prevention

I don't know what this means, but if you're implying that unique_ptr is good enough to prevent use after free in practice, that is obviously empirically false. Every browser engine, for example, uses C++11 and regularly has exploitable use after free.

Ada, FreePascal, ...?

Problem is that when you use C you get the low level coders on board relatively easily. Not always the case in other languages

When 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.

Then Cyclone or any of safe C subsets/variants.

Cyclone 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.

The author of Cyclone seems to suggest that Rust is the current path forward: 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.

Cyclone, 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.

It'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/

http://sva.cs.illinois.edu/downloads.html

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/a850dc78e65e26f8f4def4...

Galois, as usual, graciously open-sourced two of theirs (Ivory & Tower) that's already fielded in real world:

http://ivorylang.org/

Popcorn and TALC are older ones in prototype form:

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/

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

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.

Sounds 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)

Reply on news.ycombinator.com