Asahi Linux May Pursue Writing Apple Silicon GPU Driver In Rust

[cj.wijtmans]

I would rather have bad code that doesnt work/crash in C or whatever doomsday scenario rust fanboys can come up with than bad code in rust that "just works" because "it did the thing". Unit tests Fuzzers extensions and new standards exist for a reason. mixing languages seems like a bad idea since its 100k extra lines of code to maintain.

[smitty3268]

Not in this case, the GPU side are spearheaded by Alyssa Rosenzweig (https://twitter.com/alyssarzg) and Asahi Lina (https://twitter.com/LinaAsahi)

Asahi Lina is Hector Martin, behind a vtuber avatar. I honestly don't get the whole thing, but he is living in Japan. I guess it's a thing people do now?

[sabian2008]

The whole (regular, userspace) Rust standard library is “just a bunch of bindings layers” gluing pretty unsafe libc and direct syscalls. Everything in it somewhere boils down to some unsafe code calling into generally unsafe C or doing some direct pointer manipulation. And yet it allows you to write userspace programs proven to be memory safe.

Because the Rust APIs provided by those bindings encode the invariants¹ required to safely call the C functions and syscalls directly in the signatures and are enforced by the compiler. That’s the same idea of hiding the unsafety behind safe abstractions in Rust-For-Linux bindings and in any embedded Rust project.

¹stuff like “the returned pointer is valid no longer than any of the input pointers A or B live”, “this pointer cannot be mutated in another thread”, “to call this function on this object you must be holding a valid guard obtained first by that call”, “this needs to be freed using that function”, “this function cannot be called twice on the same object”, “this has to contain valid unicode characters”, etc.

Hey, but what if the libc implementation has a bug?

Rust doesn't solve the safety problem, only adds layers of bloat. I want a language which guarantees me that my program will behave mathematically perfectly under every possible circumstance one can imagine. A theorem generator of sorts.

The language I'm looking for has to prevent a muon neutrino from interacting with a gate and flipping it. If a language can't achieve this, it's not worth adopting at all.

[hwertz]

I am not a Rustafarian, I used Rust a bit and didn't care for it too much (because I prefer to work in higher-level languages like Python. Writing an initial Python driver to debug actually working with the GPU is great IMHO.) BUT, Rust is essentially C-like if you had the strictest version of lint ever, really Rust looks a lot like C but with more pedantically written code -- code that could result in a buffer overflow, access to an uninitialized variable, etc., not having code to explicitly handle all possible inputs, all result in compiler errors. I think this is an excellent place to use Rust, you have a small amount of "unsafe" Rust to access the DRM buffers being fed to the GPU driver and such, with the bulk of the code being able to be written in safe Rust. I think it's actually perfect for this use.

[Quackdoc]

Asahi Lina is Hector Martin, behind a vtuber avatar. I honestly don't get the whole thing, but he is living in Japan. I guess it's a thing people do now?

it's fun to watch when you get board of watching real people, it's more of an interesting gimmick then anything else, I tried watch asahi lina, but whatever is used for speech, whether it be text to speech or just some heavy filtering makes it unbearable for me.

[Emmanuel Deloget]

Hey, but what if the libc implementation has a bug?

All libc have bugs. All librairies have bugs, even those that forms the building block of a memory-safe language.

Rust talking points are irrelevant. Memory bugs are important but so are logic bugs - in fact, even memory-related bugs are logic bugs. And Rust does nothing to prevent them, because they are absolutely impossible to automatically prevent. Forgot to validate the certificate origin? Forgot to sanatize an attacker-provided string? Used the wrong formula to compute the session duration?

Sometimes, the developper have to think by itself and not require the compiler to do all the job for him.

So, please, dear community, can you consider stopping the war against The Other Language? Rust is a fairly good language with its strength and its limitations. C is a fairly good language with its strength and its limitations. There are things I will do in Rust, and things I will never do in Rust. There are things I will do in C, and things for which I'll never even consider C. Hell, we do have code written in Rust, C, Go, C++, shell, python, PHP, SQL and whetever the weird language GNU make uses in my company. But none of my choices have or will ever be guided by ideas such as "I will have less bugs if I use this language". That's beyond stupid.

[darkonix]

All libc have bugs. All librairies have bugs, even those that forms the building block of a memory-safe language.

That's true, all software has bugs.

Rust talking points are irrelevant. Memory bugs are important but so are logic bugs - in fact, even memory-related bugs are logic bugs. And Rust does nothing to prevent them, because they are absolutely impossible to automatically prevent. Forgot to validate the certificate origin? Forgot to sanatize an attacker-provided string? Used the wrong formula to compute the session duration?

Sometimes, the developper have to think by itself and not require the compiler to do all the job for him.

That's not really correct. There are studies by big company that all point that about 70% of security vulnerabilities are caused by memory bugs. The same memory bugs that mostly impossible to reproduce in Rust. At the least we are reducing the surface attack by a very significant percentage, even if it can never truly be eliminated. A logic bug may cause errors but maybe not cause security vulnerabilities as much.

So, please, dear community, can you consider stopping the war against The Other Language? Rust is a fairly good language with its strength and its limitations. C is a fairly good language with its strength and its limitations. There are things I will do in Rust, and things I will never do in Rust. There are things I will do in C, and things for which I'll never even consider C. Hell, we do have code written in Rust, C, Go, C++, shell, python, PHP, SQL and whetever the weird language GNU make uses in my company. But none of my choices have or will ever be guided by ideas such as "I will have less bugs if I use this language". That's beyond stupid.

Rust is also a much modern language with modern features that were probably not even a pipe dream when C was conceived 50 years ago. Still there are things that are going to be easier to do in C or some other language.

[marios]

There are studies by big company that all point that about 70% of security vulnerabilities are caused by memory bugs.

Lol, the company that shall not be named...

[qarium]

Lol, the company that shall not be named...

the most evil company human history has ever seen...

[darkonix]

Lol, the company that shall not be named...

Not so. I missed to add references (phoronix is very hard to edit in my phone for some reason).

Google, Microsoft both reached thesame conclusion independently https://blogs.grammatech.com/memory-...-google-chrome

At least two of the top CVEs in 2021 were related to out of bounds bugs.

So it makes sense to try address these preventable issues at the source since mitigation measures have proven unviable after years and years.

Logic errors are a different matter.