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)
