Received-SPF: pass (google.com: domain of linux-kernel+bounces-176820-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <59f731ab619673afec4956fce6832a1cd5324fb8.camel@tugraz.at>
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
From: Martin Uecker <uecker@tugraz.at>
To: Linus Torvalds <torvalds@linux-foundation.org>, 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
Date: Sun, 12 May 2024 10:03:30 +0200
In-Reply-To: <CAHk-=wgoE5EkH+sQwi4KhRhCZizUxwZAnC=+9RbZcw7g6016LQ@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0

Am Mittwoch, dem 08.05.2024 um 16:47 -0700 schrieb Linus Torvalds:
> On Wed, 8 May 2024 at 15:54, Kees Cook <keescook@chromium.org> wrote:
> >=20
..
>=20
> No, the only point where that actually failed was then when a
> (non-overflowing, non-wrapping) final value was assigned to a 16-bit
> field, ie the problem only ever happened at the final assignment:
>=20
>         event->read_size =3D size;
>=20
> where no overflow had ever happened before that.
>=20
> So in *that* case, you actually have a much more interesting
> situation. Not wrap-around, not overflow, but "implicit cast drops
> significant bits".
>=20
> And yes, I do think implicit integer casts are dangerous. Often *more*
> dangerous than arithmetic overflow and wrapping. We've had absolutely
> tons of them. Some of our most traditional bugs have very much been
> about implicit casting losing bits and causing problems as a result.

In principle, GCC has -Wconversions which looks like that it is
meant to catch this.  It seems not entirely stupid, e.g. it warns=C2=A0
about=C2=A0 the first assignment and not the second (x86):

void f(int i)
{
    unsigned short y =3D i;
    unsigned short x =3D i & 0xFFF;
}

But I guess it still could be smarter. Or does it have to be a
sanitizer because compile-time will always have too many false=C2=A0
positives?

Martin