[Info-vax] Rust as a HS language, was: Re: Quiet?

[Simon Clubley]

On 2022-04-08, Arne Vajhøj <arne at vajhoej.dk> wrote:
> On 4/8/2022 3:20 PM, Simon Clubley wrote:
>> On 2022-04-07, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>>>
>>> Could you perhaps provide a citation to one of these articles?
>>>
>> 
>> Interesting question. I obviously can't remember the locations of
>> the articles I found in the past, so I looked at a small sample of
>> articles returned by Google to see if I had problems with them.
>> 
>> Comments below.
>> 
>> https://dev.to/katholder/pros-and-cons-of-rust-language-313i
>> 
>> Obviously a gushing user type writeup with non of the serious
>> analysis and flaws such as unsafe code you would expect to see.
>
> That article is pretty bad. 99% filler.
>

Yes, it is. I included it because it was one of the first articles
Google returned to me when I did a search for Rust language articles.

>> https://codilime.com/blog/why-is-rust-programming-language-so-popular/
>> 
>> Mentions briefly unsafe mode
>
> There are 3 sections about it.
>
>>                               but doesn't make it clear that you can
>> invalidate _all_ the unique features and guarantees in Rust when you
>> use it.
>
> It doesn't because that is not the case.
>
> It disable some features but not all - among other things it does
> not disable memory ownership.
>

To go back to one of the examples I posted recently (which I picked at
random from a list of Rust CVEs):

https://rustsec.org/advisories/RUSTSEC-2020-0148.html

|Affected versions of this crate have the following issues:
|
|Ptr implements Send and Sync for all types, this can lead to data races by
|sending non-thread safe types across threads.
|

Avoiding data races is advertised as a core feature of Rust and this
library managed to violate that rule.

|Ptr::get violates mutable alias rules by returning multiple mutable
|references to the same object.
|

_This_ violates the core feature of Rust which is the borrow checker.

|Ptr::write uses non-atomic writes to the underlying pointer. This means
|that when used across threads it can lead to data races.

Another data races problem.

>
>> Based on the complete bypassing of Rust's unique features seen in the
>> CVEs when running in unsafe mode,
>
> Your assumption about unsafe bypassing everything is simply wrong.
>

I'd call the above examples of the complete bypassing of Rust's unique
features. And it doesn't even matter how they did it. What matters is
that they did.

>>                                     the following is either wrong or at
>> least misleading depending on how you look at it:
>> 
>> |Rust lets you live dangerously if you need to, to a point. Rust's safeties
>> |can be partly suspended where you need to manipulate memory directly, such
>> |as dereferencing a raw pointer a la C/C++. The key word is partly, because
>> |Rust's memory safety operations can never be completely disabled. Even
>> |then, you almost never have to take off the seatbelts for common use cases,
>> |so the end result is software that's safer by default.
>> 
>> Can never be fully disabled ? There are a set of CVEs that say otherwise.
>
> No.
>
> Some memory safety can be disabled by unsafe. And the CVE's are
> example of that.
>
> The CVE does not show all memory safety disabled.
>
> That is your imagination.
>

Just this one CVE shows the borrow checker being bypassed and the
eliminating data races feature of Rust also being bypassed.

I also posted another example of a traditional buffer overflow issue.

I would call this all memory safety being disabled, so no, it's not
my imagination.

>> 
>> https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html
>> 
>> Not the first time I have seen that type of mistake elsewhere. Interesting
>> that Rust can have the same problem and that it wasn't detected until now.
>
> There are still plenty of opportunities for problems in Rust.
>

Would be nice if those articles pointed that out instead of gushing
over Rust in the same way as people did over Java in the early days.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.