Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in QEMU Roadmap

lore.kernel.org

Post reply on HN
Print view View original

71–80 of 184 posts

Re: Rust in QEMU Roadmap

#71

Post by kouteiheika »

jdefr89 wrote: post #44
School-Cotton wrote: post #31

Earlier quoted context omitted.

The fact that rust makes it harder to write memory corruption bugs is only one of its many advantages. It’s genuinely a lot nicer and easier to use than comparable languages like C++, and I’d prefer it to that even if I didn’t care about memory corruption at all. Also, what’s wrong with the syntax? I hear a lot that people find the syntax ugly but I never understood what’s so fundamentally different about it compared…

What are the other advantages exactly besides tool chain? A lot of people using Rust where the could have just used Go or another language that is memory safe and actually productive. Maybe I am just being a hater because I grew up on C/C++ but I know for a fact "Rustaceans" are getting out of control. Approaching zealot territory for sure. The time people spend fighting the Rust compiler for a project, they could ha…

> What are the other advantages exactly besides tool chain?

It's a very productive language once you're experienced.

I'm one of those people who (initially) didn't care about memory safety at all and just wanted a more productive C++, and for me it delivers on that perfectly. Nowadays I even use Rust for scripting, because with the right libraries it's just as productive for me as Ruby and Python can be while being orders of magnitude faster.

I always find it funny when I see the "fighting with the borrow checker" meme, or as you say - "people spend fighting the Rust compiler for a project", where people complain how extremely unproductive Rust is. This is very much true, if you're a beginner. It's a language with a very high skill ceiling (similar to C++).

Re: Rust in QEMU Roadmap

#72

Post by pm215 »

vlovich123 wrote: post #63
tangent128 wrote: post #52

Earlier quoted context omitted.

Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down. So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories. (Not just rustup- Debian requires repackaging Cargo dependencies so tha…

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo tha…

It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment.

Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we could throw all that cooperation away and say "tough, you need to use up-to-the-minute rust, if that's a problem for distro packagers we don't care". But we want to be a good citizen in the traditional distro packaging world, as we have been up til now. Not every open source project will want or need to cater to that, but I think for us it matters.

That doesn't mean that we always do the thing that is simplest for distros (that would probably be "don't use Rust at all"); but it does mean that we take distro pain into account as a factor when we're weighing up tradeoffs about what we do.

Re: Rust in QEMU Roadmap

#73

Post by ynik »

duped wrote: post #56
galangalalgol wrote: post #27

Earlier quoted context omitted.

The one lagging thing that isn't easy with rust's generics is expressions, and that looks to be getting kicked down the road indefinitely. You can't have Foo * Foo -> Foo or similar. That is a useful thing for statically sized math libraries and for performance oriented metaprogramming. The latter can be clumsily handled with macros, but not the former. It is also blocking portable simd from stabilizing, apparently n…

> You can't have Foo * Foo -> Foo or similar. You can though, unless I totally misunderstand your syntax use std::{marker::PhantomData, ops::{Add, Mul}}; pub struct Foo { _p: PhantomData , } impl Mul > for Foo where N: Add { type Output = Foo >::Output>; fn mul(self, rhs: Foo ) -> Self::Output { todo!() } }

You misunderstood. N, M are supposed to be integers (const generics); in your example code you've made them types. Also, your `type Output = Foo>::Output>;` just means "multiplication has the same return type as addition". But desired is that multiplying a Foo with a Foo results in a Foo.

Rust decided that it's important to not have instantiation-time compiler errors, but this makes computation with const generics complicated: you're not allowed to write Foo because N+M might overflow, even if it never actually overflows for the generic arguments used in the program.

Re: Rust in QEMU Roadmap

#74

Post by jujube3 »

sureglymop wrote: post #40
jdefr89 wrote: post #29

[flagged]

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In m…

Read his comment. This guy literally writes exploits for C/C++ software. Of course he wants you to keep using memory-unsafe languages, otherwise his business dries up!

Re: Rust in QEMU Roadmap

#75

Post by dboreham »

crabbone wrote: post #34
tejohnso wrote: post #24

Earlier quoted context omitted.

What are the advantages of trying to use fake c++ instead of actual c++ for their use case? I'm sure there are / were smart people working on the project. Do they keep decision records? Have you had a conversation with the relevant people about it?

I worked for a large infra project that was mostly written in C with the kind of trickery that is being here ascribed to QEMU code (I trust the parent, but I haven't seen the code myself). It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with…

I was going to post the same thing. Others on this thread may not have had experience with very large C codebases and hence haven't seen this play out. To a large degree C++ is just capturing what was already widespread practices in C, and indeed assembly before that.

Re: Rust in QEMU Roadmap

#76

Post by 0x457 »

bonzini wrote: post #66
JoshTriplett wrote: post #45

Earlier quoted context omitted.

> Right now the only language-level thing I would like is const operator overloading. As far as I know, const traits are still on track. > easier passing of closures from Rust to C As in, turning a Rust closure into a C function-pointer-plus-context-parameter? > The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standa…

> As far as I know, const traits are still on track. Yes they are. My use case is something like the bitflags crate, there are lots of bit flags in emulated devices of course. In the meanwhile I guess it would be possible to use macros to turn something like "bit_const!(Type:A|B)" to "Type(A.0|B.0)" or something like that. > As in, turning a Rust closure into a C function-pointer-plus-context-parameter? Yes, more in…

I made this handy function to pass callbacks to C: https://github.com/andoriyu/uclicious/blob/master/src/traits...

Re: Rust in QEMU Roadmap

#77

Post by vlovich123 »

ronsor wrote: post #68
vlovich123 wrote: post #63

Earlier quoted context omitted.

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo tha…

> As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. Most toolchains don't have as much churn as Rust.

Disagree. No stable release of Debian today supports c++23 which is coming up on two years old at this point (this corresponds to a major Rust edition, not the minor stuff they publish on an ongoing basis every month).

Java in Bookworm installs JDK 17 which is three years old at this point. Java itself is on 23 with 21 being an LTS release.

This means that upstream users intentionally maintain an old toolchain just to support Debian packaging or maintain their own deb repo with newer tools.

You’re confusing cause and effect. People aren’t migrating because Debian packaging lags so badly, not because there aren’t improvements projects would love to otherwise use.

Re: Rust in QEMU Roadmap

#78

Post by vlovich123 »

pm215 wrote: post #72
vlovich123 wrote: post #63

Earlier quoted context omitted.

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo tha…

It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we…

To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the Debian maintainers to backport patches.

Re: Rust in QEMU Roadmap

#79

Post by vlovich123 »

jdefr89 wrote: post #41
vlovich123 wrote: post #32

Earlier quoted context omitted.

> Exploiting mature software like Adobe Reader is already incredibly challenging due to its hardened defenses. Is this a troll? Isn’t Adobe Reader one of the easiest pieces of software to exploit because it enables risky features by default and lacks proper sandboxing? Just searching for “adobe reader security vulnerability” brings up a critical software update for CVE-2023-26369 as a top hit which is: > Acrobat Read…

Developing a full kill chain for adobe usually requires chaining together several bugs. "CVEs" are getting ridiculous. Prove to me it is easy and go win Pwn2Own or you can do what I do. Sell it to government contractors for a hefty price...

It doesn’t matter about easy or hard. It’s possible and then we’re just talking about the $ required to purchase it on the black market - government contractors don’t really pay well unless I’m misinformed. And a vulnerability remains a vulnerability forever until your victims patch it.

Said another way. Based on CVEs most of the focus of attackers is on memory safety vulnerabilities which means that regardless of price they otherwise fetch, these are still the cheapest and most valuable exploits to uncover in terms of exploit power / dollar spent.

Re: Rust in QEMU Roadmap

#80

Post by pm215 »

vlovich123 wrote: post #78
pm215 wrote: post #72

Earlier quoted context omitted.

It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we…

To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the…

I think that trust would be somewhat misplaced -- QEMU has historically not made particularly timely security fixes either on mainline or on branches. To the extent that our stable-branch situation is better today than it was some years ago, that is entirely because the person who does the downstream Debian packaging stepped up to do a lot more backporting work and stable-branch maintenance and releases. (I'm very grateful for that effort -- I think it's good for the project to have those stable branch releases but I certainly don't have time myself to do that work.)

As an upstream project, we really don't want to be in the business of making, providing and supporting binary releases. We just don't have the volunteer effort available and willing to do that work. It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams.

Post reply on HN