Received-SPF: pass (google.com: domain of linux-kernel+bounces-173211-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: David Laight <David.Laight@ACULAB.COM>
To: 'Kees Cook' <keescook@chromium.org>, Linus Torvalds
	<torvalds@linux-foundation.org>
CC: Justin Stitt <justinstitt@google.com>, Peter Zijlstra
	<peterz@infradead.org>, Mark Rutland <mark.rutland@arm.com>,
	"linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>
Subject: RE: [RFC] Mitigating unexpected arithmetic overflow
Thread-Topic: [RFC] Mitigating unexpected arithmetic overflow
Thread-Index: AQHaoNrkK91jQ1nmYEmzGISNIfAGlrGNP8bg
Date: Wed, 8 May 2024 12:22:38 +0000
Message-ID: <e777a057e8d246efbc90381c2988b9b2@AcuMS.aculab.com>
References: <202404291502.612E0A10@keescook>
In-Reply-To: <202404291502.612E0A10@keescook>
Accept-Language: en-GB, en-US
Precedence: bulk
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

From: Kees Cook
> Sent: 08 May 2024 00:28
>=20
> Over the last decade or so, our work hardening against weaknesses
> in various kernel APIs and eliminating the ambiguities in C language
> semantics have traditionally been somewhat off in one corner or another
> of the Linux codebase. This topic is going to be much different as
> it is ultimately about the C type system, which is rather front and
> center. So, hold on to your hats while I try to explain what's desired
> here. Please try to reserve judgement until the end; as we've explored
> the topic we've found a lot of nuances, which I've tried to touch on
> below. I'm hoping folks can have an open mind about all this and not
> jump to any conclusions without first hearing me out. :)
>=20
>=20
> Problem to Solve
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The Linux kernel has consistently suffered from unexpected arithmetic
> overflow bugs. These lead to any number of exploitable conditions[0].
> Our continuing efforts to improve things (refcount_t, alloc_size(),
> etc) have helped in some specific areas, but on the whole, we've had a
> relatively unchanged count of serious arithmetic overflow flaws over the
> life of the project[1]. This is not tolerable, and we should, all of us,
> make the effort needed to put an end to it in a systematic way.

Is it April 1?

Have you estimated the performance cost of checking the result of
all integer arithmetic.

If you have a cpu with 'signed/unsigned add(etc) with trap on overflow'
instructions then maybe you could use them to panic the kernel.
But otherwise you'll need a conditional branch after pretty much
every arithmetic instruction.
As well as the code bloat there is likely to be a 50% chance they
are mis-predicted slowing things down a lot more.
IIRC at least some x86 cpu do not default to static prediction (eg
backwards taken forwards not) but always use data from the branch
prediction logic - so the first time a branch is seen it is predicted
randomly.

=09David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1=
PT, UK
Registration No: 1397386 (Wales)