Re:New fuzzing tool finds USB bugs in Linux, Windows, macOS,...
by pml1 on Thursday May 28, 2020 @10:17AM
(#23337510)
>So there will of course be some unsafe. In a well implemented driver it will also be very limited in scope and relatively easy to check.
I'm sure that is what the C developer thought as well...I'm not trying to be snarky, but that same arguments that are made against C code holds equally true for unsafe code...
I don't think it is a reasonable position to suggest that unsafe Rust code is somehow safer than C code...
Re:New fuzzing tool finds USB bugs in Linux, Windows, macOS,...
by gpm on Thursday May 28, 2020 @10:56AM
(#23338019)
The point isn't that unsafe rust code is safer than C code, but that there is many orders of magnitude less unsafe rust code than c code in a driver of the same size.
Re:New fuzzing tool finds USB bugs in Linux, Windows, macOS,...
by teknopaul on Thursday May 28, 2020 @06:21PM
(#23343563)
Unsafe rust is safer than C for two reasons.
You can limit what comes in from safe rust.
Unsafe rust still has more compiler checks than C. Unsafe rust is not as permissive as C. Its rust still, with certain things permitted.
Its unsafe{} not nosafe{}
Drivers are a fundamentally unsafe concept, like an ffi call, you're talking to hardware the compiler doesn't understand and assuming it's going to do what you want. So there will of course be some unsafe. In a well implemented driver it will also be very limited in scope and relatively easy to check.
I can't vouch for the code quality (I just don't know how good it is, I had no hand in writing it, and it's not used in a production system), but I believe you can find a usb driver implementation written in rust here: https://gitlab.redox-os.org/redox-os/drivers/-/tree/master/x...