Earlier quoted context omitted.
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.
Rust in QEMU Roadmap
111–120 of 184 posts
Re: Rust in QEMU Roadmap
#112Earlier quoted context omitted.
> 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.
I read it. He's not saying what you seem to think he's saying.
That aside, any solution that involves tooling people have to opt into is doomed to fail. We've seen this a thousand times throughout history: if you require people to go out of their convenience to choose the safer option, they won't do it. It doesn't matter how great the tools are. How cheap they are. How easy they are. If they're not part of the standard pipeline everyone gets unless they deliberately modify it, they won't be used.
You've said a few times that C/C++ have tools that get you most of the same controls as Rust. First, they don't. But even if they did, those tools aren't used by default. Rust makes everyone write code that satisfies the borrow checker whether they want to or not. There's no `-Wborrow-mistakes` flag we have to set. There's not even a `-Wno-borrow-mistakes` flag we can turn off if we get tired of the error message. If you write Rust, borrows are safe, and we don't get a say in it.
You can write C code that satisfies Coverity (where I use to work) and `-Wall` and Valgrind and and and, but the person next to you might not. And as long as it's easier to write unchecked C than to run it through a tester before validation, it won't be as safe as Rust at the things Rust checks. It can't be. Anything that depends on humans to make the safe choice is dead before it starts.
Re: Rust in QEMU Roadmap
#113Earlier 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…
aiui this isn't inherently limited by instantiation-time error messages and is available on nightly today with the generic_const_exprs feature. It's in the pipeline.
Re: Rust in QEMU Roadmap
#114Earlier quoted context omitted.
By "the Rust community" here, you mean the author of the mail, one of the biggest long-standing developers of QEMU since before Rust was a thing? You're complaining that the developers of QEMU themselves are interested in adopting Rust because they think it'll work well for them?
> one of the biggest long-standing developers How many developers does the project have? What is your metric for "biggest?" Just total number of contributions? > You're complaining that the developers of QEMU themselves Yep. Do any of them work for any commercial companies? Or are we ignoring that to make an argument of appeals? If they all left would QEMU have zero developers? > because they think it'll work well fo…
What leg do you think you have to stand on when it comes to Rust in Linux? Linus Torvalds is fine with the Kernel experimenting with Rust.
Re: Rust in QEMU Roadmap
#115[flagged]
> I am convinced the syntax was intentionally developed to troll us all with the ugliest syntax on the planer..
Not a troll. Just a bit too concessionary to C++ developers. :)
Re: Rust in QEMU Roadmap
#116Earlier 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…
> 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.
This is a perfectly level-headed submission about trying out Rust in some corner of the Linux Kernel. Which you then take as an opportunity to go on this rant... I’ll let people read my conclusion between the lines.
Re: Rust in QEMU Roadmap
#117Earlier quoted context omitted.
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…
C++'s metaprogramming is still better. Rust needs specialization, const expressions, and a bunch of other things before it can be a full replacement for C++.
You’re right, but most people who are still using C++ over rust aren’t doing so because of better metaprogramming. It’s a relatively minor advantage, and on the other side, the advantages of Rust over C++ are massive.
Re: Rust in QEMU Roadmap
#118Earlier quoted context omitted.
> " Sure just wrap everything in "Unsafe"... So what is the point? " https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe…
You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.
For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project (https://github.com/MaterializeInc/materialize) and anecdotally, unsafe code was much less than 1% of the codebase.
Re: Rust in QEMU Roadmap
#119Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit on the safe abstractions that are mentioned in the roadmap).
> 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…
> define the base via union of all bases in the chain [...] just checks 3 things in order
Can you please show a concrete example? Thanks.
Re: Rust in QEMU Roadmap
#120Earlier quoted context omitted.
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…
You can define your own "language", the way you describe it, in C++ more easily than you can in C. C++ gives you more powerful and expressive tools for doing so. A program is not improved by foregoing these tools. There's nothing in C++ forcing you to do anything that makes anything "harder".
I wouldn't be so quick to put "easy" and "C++" in the same sentence... Also, C and C++ language tools suck, when it comes to making a language compared to anything in Lisp family, for example, or any language that has Lisp-like macros. C wasn't chosen for it's ability to make other languages. It was an easy target. The benefits are the simpler and more malleable runtime that can be made to do all sorts of weird things where C++ would be much harder to deal with.
In other words, if you don't want the language runtime, if you don't want C++ templates, smart pointers, classes, lambdas, exceptions etc. But, you want to be able to manage memory for eg. realtime kind of system... simply removing all the unwanted stuff from C++ is harder than it is with C.
And, if you did want some / all of those features of C++, there are saner languages to have that (and you'd pay for it by having to drag in their runtime and conventions). Before Rust was a thing, I've seen people choose D instead, for example, as a kind of middle ground between the asceticism of C and unnecessary excess of C++.