Re: The Case for Rust (in any system)

On Thu, Sep 5, 2024 at 4:51 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> sigh.  now i am back.
>
> ske-89@pkmab.se wrote in
>  <202409052313.aa18097@berenice.pkmab.se>:
>  |Alan Somers <asomers@freebsd.org> wrote:
>  |> In fact, of all the C bug fixes that I've been involved with (as
>  |> either author or reviewer) since May, about three quarters could've
>  |> been avoided just by using a better language.
>  |...
>  |> To summarize, here's the list of this week's security advisories, and
>  |> also some other recent C bug fixes of my own involvement:
>  |
>  |After checking several of these examples, I'm wondering what the code
>  |would have looked like in some "better language", where those bugs would
>  |have been avoided?
>
> Examples.  I find the absolute opposite after checking four.
> Ie, if you implement some SCSI command
>
>   -
>   -     /*
>   -      * struct scsi_sense_data, which is currently set to 256 bytes, is
>   -      * larger than the largest allowed value for the length field in the
>   -      * REQUEST SENSE CDB, which is 252 bytes as of SPC-4.
>   -      */
>   -     ctsio->kern_data_len = cdb->length;
>   -     ctsio->kern_total_len = cdb->length;
>   +     ctsio->kern_data_len = ctsio->kern_total_len =
>   +         MIN(cdb->length, sizeof(*sense_ptr));
>
> This is a super clear logic error, that even says the comment,
> which did not care for security related impacts.  It came in as
> part of a tremendious super large patch "Add the CAM Target Layer
> (CTL)." (130f4520cba830cc6da47c9f871fed78710a4709) in 2012, 34000
> lines of code additions.  There were a couple of fixup commits.
> It seems to have been sponsored, but i have no idea of review or
> anything.  Compared to the WireGuard stuff, for example.
> Now i had to look more deeply why the commit says three bytes
> whereas the naive eye counts four.  (Maybe NUL terminated.)
>
> The ones from OpenSSL and ctld are more complex.  But the libnv is
> pretty clear again, it even uses strnlen() (urgh).
>
>  |E.g for the "use after free" or "unitialized memory" examples.
>
> Examples.  You are just saying.
>
>  |To me, several of those bugs seem fairly complex, and not just a
>  |question of having bounds checking for arrays or a borrow checker
>  |for pointers, or something simple like that.
>
> Two of four.
>
>  |But maybe the bugs could have been detected[.]
>
> yes, maybe.  I doubt it.
>
>  |[.] and prevented if the
>  |code would have been forced to be expressed in a completely
>  |different manner by some other language? Or what is your vision
>  |of how that would be accomplished?
>
> Actually yes.  String objects.
> I mean it is easy to say that, but if you look at the SCSI thing,
> one would normally do things like eg
>
>   we_parse_THIS_SCSI_COMMAND([.]u8 *buf, u16 len){
> ...
>         /* C99 */{
>                 struct a_mmc_cmd_x42_resp_data_head *dhp;
>
> ^argument etc of THIS_SCSI_COMMAND
>
>                 dhp = R(struct a_mmc_cmd_x42_resp_data_head*,buf);
>                 buf += sizeof(*dhp);
>                 len -= sizeof(*dhp);
>         }
> ...
>         irp = R(struct a_mmc_cmd_x42_isrc_resp*,buf);
>
> Unfortunately it was forgotten for one of many use cases, where
> a byte buffer of reality matches a structure of a language
> abstraction.  How could a different language aid here.
>
>  |You seem to be saying that certain examples would be solved by
>  |a better language, and certain ones would not, so I suppose you
>  |do have some vision of how that would work.
>
> And *i* am saying that for example the nvlist could have been done
> very safely in C, if instead of strnlen() etc something more sane
> would have been used.  Like a string object.  But it is more
> typing work etc.  *That* of course, yes.
>
>  |I'm just curious to learn more, since it is not obvious to me,
>  |and thus all the more interresting.
>
> This is all very unspecific.  I have also seen quite a lot of
> things.  What should be the answer to this unspecific question,
> except continuation of this thread?

I'm having trouble following your English, but you seem to be missing
the point.  The point is not whether the bugs can be fixed in C; of
course they can, after all we just did.  The point is that safe
programming languages make it nearly impossible to create the bugs in
the first place.  For example, a language that uses RAII everywhere
makes it nearly impossible to allocate a structure without
initializing it.  Nearly impossible to leak memory, too.

>
>  |/Kristoffer Eriksson
>  --End of <202409052313.aa18097@berenice.pkmab.se>
>
> In support for that swedish hm virgin, yes, sweden is not a clean
> country for sure.

Again, I don't know what you mean.  But it looks like a personal
attack to me.  Please try to keep your discourse on the public mailing
lists respectful.

-Alan