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

41–50 of 184 posts

Re: Rust in QEMU Roadmap

#41

Post by jdefr89 »

vlovich123 wrote: post #32
jdefr89 wrote: post #29

[flagged]

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

Re: Rust in QEMU Roadmap

#42

Post by jdefr89 »

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…

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

Re: Rust in QEMU Roadmap

#43

Post by bobajeff »

qalmakka wrote: post #26
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?

C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though. IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will ine…

The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.

Re: Rust in QEMU Roadmap

#44

Post by jdefr89 »

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

[flagged]

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 have just written secure C.. That is just my personal opinion. I am not saying Rust shouldn't exist. I am just saying it isn't some big universal answer to all security and systems programming issues..

Re: Rust in QEMU Roadmap

#45

Post by JoshTriplett »

bonzini wrote: post #13
JoshTriplett wrote: post #12

Earlier quoted context omitted.

What does your wishlist for Rust look like? (Besides "simpler C/Rust interoperability", of course.) Has QEMU run into things that Rust-for-Linux hasn't, that feel missing from the Rust language?

Right now the only language-level thing I would like is const operator overloading. Even supporting MSRV as old as 1.63 was not a big deal, the worst thing was dependencies using let...else which we will vendor and patch. Pin is what it is, but it is mostly okay since I haven't needed projection so far. Initialization using Linux's "impl PinInit " approach seems to be working very well in my early experiments, I cont…

> 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 standardization of core FFI traits would be nice.

Would be happy to work with you to get something on the calendar.

Re: Rust in QEMU Roadmap

#46

Post by jdefr89 »

nazgulsenpai wrote: post #37
jdefr89 wrote: post #29

[flagged]

I agree the rewrite everything in Rust meme is overblown, and the Rust evangelists can be insufferable. I also agree that, at a glance, Rust syntax is (in my opinion) quite ugly. Once you start using the language it makes more sense why things are the way they are, but it was offputting to me at first and I still think its ugly now. However I don't think adding Rust support, rewriting old, critical components, using…

I understand that. It is just they end up writing Rust code and then you go and see it's linked to libc or filled with "Unsafe". It isn't too difficult to write correct, safe C++. You can enable compiler settings that are similar to what Rust does..

On the critical bugs issue... To exploit a lot of these memory bugs it takes an entire new level of effort. We often need to chain together three or more bugs and land the exploit reliably.. This was much easier to do circa 2001 - 2016 but all the mitigations in place have really raised the bar.. From my experience providing exploits to a red teams that pen-test fortune 500 companies (my previous job at iDefense/FusionX), things have gotten far far more difficult. Rarely needed to use any advanced "sexy kill-chains" (like Chrome or IE exploit) because phishing and other means of network entry were far more reliable and much easier. My point is that study Google released expressed the bugs are dangerous and disastrous, yes, but they aren't the most prevalent risk in the real world. I am rambling a bit. Sorry for poor grammar typing on phone.

Re: Rust in QEMU Roadmap

#47

Post by hmry »

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…

> The time people spend fighting the Rust compiler for a project, they could have just written secure C

I simply don't believe this anymore, based on the number of buffer overflow and memory corruption CVEs coming out of even mature C codebases every year

Re: Rust in QEMU Roadmap

#48

Post by [deleted] »

Neywiny wrote: post #21

I've said this before on here and I'll say it again. The QEMU code base is a nightmare. The amount of fake C++ is mind numbing. Every time I come across a variable or strict declaration or method with the word "class" in it, I'm reminded of how much easier the whole thing would've been with C++. You can't even compile C++ into QEMU because of how the headers use keywords. That's not even touching their macro abuse te…

[deleted]

Re: Rust in QEMU Roadmap

#49

Post by [deleted] »

vlovich123 wrote: post #35

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

[deleted]

Re: Rust in QEMU Roadmap

#50

Post by jdefr89 »

hmry wrote: post #47
jdefr89 wrote: post #44

Earlier quoted context omitted.

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…

> The time people spend fighting the Rust compiler for a project, they could have just written secure C I simply don't believe this anymore, based on the number of buffer overflow and memory corruption CVEs coming out of even mature C codebases every year

CVEs are being assigned recklessly these days. Most of them aren't even security bugs and or cannot be exploited. Be wary of CVEs and their practical utility.

Also this is a good read from AFL creator lcamtuf: https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-...

Post reply on HN