linux-kernel - Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop

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] [day] [month] [year] [list]

Message-ID: <9472f9dc97beb069e3dbcc0ab6c8e9b5c6976a33.camel@tugraz.at>
Date:   Wed, 02 Mar 2022 08:27:54 +0100
From:   Martin Uecker <uecker@...raz.at>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
 after the loop

Am Dienstag, den 01.03.2022, 12:26 -0800 schrieb Linus Torvalds:
> On Mon, Feb 28, 2022 at 5:50 AM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
> > But making it non-UB in the standard does not force a project to
> > consider it "not an error", which is what actually matters for being
> > able to use UBSan effectively or not.
> 
> Absolutely.
>
> I think people should treat UBsan and friends a bit like "runtime lint".
> 
> "lint" traditionally doesn't necessarily check for just *incorrect* C.
> 
> It checks for things that can be confusing to humans, even if they are
> 100% completely conforming standard C.
>
> Classic example: indentation. Having the wrong indentation is not in
> any shape of form "undefined behavior" from a C standpoint, but it
> sure is something that makes sense checking for anyway.

You can automatically re-indent code form
other sources without breaking it. Assume you
have code that relis on signed integer wrapping,
but you want to use UBSan to screen for possible
signed arithmetic errors  and/or have it trap
in production to protect against exploits. You
would then have to carefully analyze each
individual case of signed arithmetic whether
it makes sense, and then somehow add an
annotation that it is actually ok (or rewrite
it which introduces new risks). This does not
seem comparable to indentation at all.

On the other hand, if you have a self-contained
code base and like wrapping signed integer, you
can now use a compiler flag and also get what
you want.

So I am still not yet convinced that the
standard was wrong making it undefined. 

Whether it is wise for compilers to use it
aggressively for optimization is a different
question...

Martin