Received-SPF: pass (google.com: domain of linux-kernel+bounces-173966-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <202404291502.612E0A10@keescook> <CAHk-=wi5YPwWA8f5RAf_Hi8iL0NhGJeL6MN6UFWwRMY8L6UDvQ@mail.gmail.com>
 <202405081144.D5FCC44A@keescook> <CAHk-=wjeiGb1UxCy6Q8aif50C=wWDX9Pgp+WbZYrO72+B1f_QA@mail.gmail.com>
 <202405081354.B0A8194B3C@keescook> <CAHk-=wgoE5EkH+sQwi4KhRhCZizUxwZAnC=+9RbZcw7g6016LQ@mail.gmail.com>
In-Reply-To: <CAHk-=wgoE5EkH+sQwi4KhRhCZizUxwZAnC=+9RbZcw7g6016LQ@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 8 May 2024 17:23:08 -0700
Message-ID: <CAHk-=wgf5mpRT_Aiw9aebX_z0i49aUbUBEPr6jk_dUaCTuR6cw@mail.gmail.com>
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
To: Kees Cook <keescook@chromium.org>
Cc: Justin Stitt <justinstitt@google.com>, Peter Zijlstra <peterz@infradead.org>, 
	Mark Rutland <mark.rutland@arm.com>, linux-hardening@vger.kernel.org, 
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"

On Wed, 8 May 2024 at 16:47, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So *that* I feel could be something where you can warn without a ton
> of compiler smarts at all. If you see an *implicit* cast to unsigned
> and then the subsequent operations wraps around, it's probably worth
> being a lot more worried about.

Side note on this part: quite often, because of C promotion rules, you
have "int" as an "intermediate" type.

IOW, while I had that example of

        int a;
        ...
        a * sizeof(xyz);

being questionably not-UB (because "int a" gets promoted to unsigned
as part of C integer promotion, and thus you really had a signed value
that was involved in unsigned wrap-around), if you have

        unsigned short a;
        ...
        a * sizeof(xyz);

then technically that 'a' is first promoted to 'int' (because all
arithmetic on types smaller than int get promoted to int), and then it
gets promoted to size_t because the multiply gets done in the bigger
type.

So in one sense that unsigned multiply may actually have involved a
cast from a signed type, but at the same time it's not at all in that
kind of "accidentally not UB" class.

I suspect most compilers would have combined the two levels of
implicit casts into just one, so at no point outside of perhaps some
very intermediate stage will it show as a signed int cast to unsigned,
but I thought I'd mention it anyway. Implicit casts get nasty not just
in assignments, but also in these kinds of situations.

I still suspect the "implicit truncating cast at assignment" is likely
a much more common case of loss of information than actual arithmetic
wrap-around, but clearly the two have commonalities.

              Linus