linux-kernel - Re: [PATCH 0/6] Initial Rust V4L2 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZDWQXDRknzFhngyk@1wt.eu>
Date:   Tue, 11 Apr 2023 18:52:44 +0200
From:   Willy Tarreau <w@....eu>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Daniel Almeida <daniel.almeida@...labora.com>,
        wedsonaf@...il.com, ojeda@...nel.org, mchehab@...nel.org,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

On Tue, Apr 11, 2023 at 04:13:36PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 2:49 PM Willy Tarreau <w@....eu> wrote:
> >
> > This might sound strange, but I suspect that having a TAINT_RUST flag
> > could possibly help maintainers that are already lacking time, because
> > it may quickly allow some of them to ask "please try again without the
> > Rust code to see if the problem is still there", just like happens with
> > out-of-tree code for which the knowledge is limited to null. This could
> > allow to route issue reports to one maintainer when an issue is confirmed
> > in both cases or to another one when it only happens in a single case.
> >
> > Of course it will not help with code reviews but we know that a great
> > part of maintainers' time it spent trying to analyse problem reports
> > that happen under vague conditions. All the time not spent debugging
> > something not well understood is more time available for reviews.
> 
> You can already ask to disable `CONFIG_RUST`.
> 
> In fact, we asked that a few times, when people reported a problem
> that looked unrelated to Rust, to confirm that was the case and thus
> redirect the report.
> 
> So it is definitely a good idea to ask for that when you get a report
> with `RUST=y` and you suspect it may be related to that, especially in
> the beginning where `RUST=y` should not be common.

But if that code is only under a module, there's no need to turn all
that code off if it's sufficient to be certain the module was no loaded.
Plus it's more friendly to the user who doesn't have to rebuild a kernel,
just blacklist a module and check that the kernel doesn't get tainted
again.

> However, I think Rust in-tree code is different to out-of-tree code,
> since you do have the code, and thus (in general) you should be able
> to reproduce the build, and you can ask for help to the given
> maintainers to understand it.

It could depend on the layer where it plugs and the level of intimacy
with the core. Sometimes you need a deep understanding of all interactions
between elements to imagine possible scenarios.

Cheers,
Willy