linux-kernel - RE: [RFC] Mitigating unexpected arithmetic overflow

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: <e777a057e8d246efbc90381c2988b9b2@AcuMS.aculab.com>
Date: Wed, 8 May 2024 12:22:38 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Kees Cook' <keescook@...omium.org>, Linus Torvalds
	<torvalds@...ux-foundation.org>
CC: Justin Stitt <justinstitt@...gle.com>, Peter Zijlstra
	<peterz@...radead.org>, Mark Rutland <mark.rutland@....com>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"llvm@...ts.linux.dev" <llvm@...ts.linux.dev>
Subject: RE: [RFC] Mitigating unexpected arithmetic overflow

From: Kees Cook
> Sent: 08 May 2024 00:28
> 
> 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. :)
> 
> 
> Problem to Solve
> ================
> 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.

	David

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