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

101–110 of 184 posts

Re: Rust in QEMU Roadmap

#101

Post by bluGill »

melon_tusk wrote: post #98
kouteiheika wrote: post #71

Earlier quoted context omitted.

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

"as productive as Ruby or Python" So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python. I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, n…

In C++ I have learned the patterns and so I rarely need to worry about lifetime - everything is either on the stack or a unique_ptr. Even when I need to take a pointer I know I don't own it but my project has clear lifetime rules and so I normally won't run into issues.

The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.

Re: Rust in QEMU Roadmap

#102

Post by jdefr89 »

dralley wrote: post #93
jdefr89 wrote: post #88

Earlier quoted context omitted.

Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.

Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontro…

Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.

Re: Rust in QEMU Roadmap

#103

Post by jdefr89 »

kstrauser wrote: post #89
jdefr89 wrote: post #29

[flagged]

> Binary exploitation is my field of expertise. > Creating an entire language to prevent such bugs is excessive, especially given the current state of software security. I'm having a hard time reconciling those 2 statements. I can imagine any 1 person having one or the other of those opinions, but not both at the same time. > Meanwhile, the vast majority of security issues (around 98%) come from basic human errors, s…

Lcamtuf, the creator of afl shares the same opinion… I linked to his Substack in my original comment. Give that a read. My main point is over emphasis on memory safety doesn’t seem to pay off when there are lower hanging fruits on most large networks.. obviously I want memory safety, but that’s irrelevant when there are easier attack vectors still open.

Re: Rust in QEMU Roadmap

#104

Post by jdefr89 »

jodrellblank wrote: post #65
jdefr89 wrote: post #29

[flagged]

> "The current trend of rewriting everything in Rust is out of control and misguided... EDIT: lcamtuf does a great job explaining my perspective on Rust push https://lcamtuf.substack.com/p/a-reactionary-take-on-memory- ... " The current trend is people rewriting Unix command line utilities in Rust, as a hobby. Nobody is rewriting Adobe PhotoShop or Oracle in Rust. Can you name some projects which you class as "out of…

Alright so I exaggerated a bit for sure. But I am seeing way too much “Rust in the silver bullet” nonsense…

Re: Rust in QEMU Roadmap

#105

Post by jdefr89 »

School-Cotton wrote: post #62
jdefr89 wrote: post #53

Earlier quoted context omitted.

A team can learn and start using Golang in a week. That is in fact what is powering a lot of companies right now. Golang has even better memory safety guarantees than Rust and you don't really need to worry about memory management at all... Furthermore its compiled statically and more suitable for distribution and horizontal scaling. I am not sure how quickly a team can become productive in Rust but I am willing to b…

> A team can learn and start using Golang in a week True, but why should we be optimizing for the first week experience? Your career lasts 40 years. > Golang has even better memory safety guarantees than Rust That is not true. What specific example did you have in mind? As an example of something Rust can enforce that Go can’t is not mutating something that’s shared between threads without acquiring the proper lock.…

There is Zig and a couple others. Rust borrows those features from functional languages they aren’t new innovations by any means..

Re: Rust in QEMU Roadmap

#106

Post by vlovich123 »

pm215 wrote: post #80
vlovich123 wrote: post #78

Earlier quoted context omitted.

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 gr…

These two statements to me seem contradictory:

> QEMU has historically not made particularly timely security fixes either on mainline or on branches

> It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams

Am I correct that this is essentially saying "we're going to do a snapshot of the software periodically but end users are responsible for applying patches that are maintained by other users as part of building"? Where do these security patches come from and how do non-Debian distros pick them up? Are Arch maintainers in constant contact with Debian maintainers for security issues to know to apply those patches & rebuild?

Re: Rust in QEMU Roadmap

#107

Post by kouteiheika »

melon_tusk wrote: post #98
kouteiheika wrote: post #71

Earlier quoted context omitted.

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

"as productive as Ruby or Python" So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python. I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, n…

> So you basically never have to worry about lifetimes or memory management or the borrow checker?

Yes. Once you're experienced enough you naturally start writing code which satisfies the borrow checker and you never really have to think about it. At least that's how it is for me.

> Because that would be a prerequisite for it to be as productive as Python.

It's not that hard to be more productive than Python for a lot of tasks, simply because Python isn't actually the most productive language in a lot of cases, it's just the most well known/most popular. (:

I do a lot of data processing in my scripts, and for many years my default was to use Ruby. The nice thing about Ruby is that things which take 3~4 lines of Python usually only take 1 line of Ruby and are significantly more convenient to do (e.g. it has proper map/filter/etc., nice multiline lambdas, regex matching is integrated into the language, shelling out to other processes is convenient and easy, etc.), which translates into significant productivity savings when you just want to whip up a script as fast as possible.

So some time ago I started writing my scripts in Rust instead of Ruby (because I often deal with multi-gigabyte files, so the slowness of Ruby started to be a problem; otherwise I would have kept using Ruby). And I've made myself a small custom library that essentially allows me to use Ruby-like APIs in Rust, and it's remarkable how well that actually worked. I can essentially write Ruby-flavored Rust, with Ruby-like productivity, but get Rust-like performance.

Re: Rust in QEMU Roadmap

#108

Post by o11c »

bonzini wrote: post #61
o11c wrote: post #55

Earlier quoted context omitted.

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. Ther…

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." :D Though I admit that Rust also has to include the full list of base classes ( https://github.com/rust-lang/rfcs/pull/1268 would fix it).

The main reason the C version must hard-code is because C macros can't be recursive. What's Rust's excuse?

(that said, the C approach is also nice for manually accessing fields of distant base classes)

Re: Rust in QEMU Roadmap

#109

Post by pm215 »

vlovich123 wrote: post #106
pm215 wrote: post #80

Earlier quoted context omitted.

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 gr…

These two statements to me seem contradictory: > QEMU has historically not made particularly timely security fixes either on mainline or on branches > It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams Am I correct that this is essentially saying "we're going to do a snapshot of the software periodically but end users are responsible for applying…

Security patches are usually developed by upstream devs and get applied to mainline fairly promptly[1], but you don't want to run head-of-git in production. If you run a distro QEMU then the distro maintainers backport security fixes to whatever QEMU they're currently shipping and produce new packages. None of this is particularly QEMU specific. There's a whole infrastructure of security mailing lists and disclosure policies for people to tell distros about security bugs and patches, so if you're a distro you're going to be in contact with that and can get a headsup before public disclosure.

[1] and also to stable branches, but not day-of-cve-announcement level of urgency.

Re: Rust in QEMU Roadmap

#110

Post by Ar-Curunir »

ynik wrote: post #73
duped wrote: post #56

Earlier quoted context omitted.

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

I believe this kind of stuff is being worked on.
Post reply on HN