linux-hardening - 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: <20240516140951.GK22557@noisy.programming.kicks-ass.net>
Date: Thu, 16 May 2024 16:09:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <kees@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Justin Stitt <justinstitt@...gle.com>,
	Mark Rutland <mark.rutland@....com>,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
	llvm@...ts.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow

On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
> 
> 
> On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra <peterz@...radead.org> wrote:
> >On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> >> For example, the most common case of overflow we've ever had has very
> >> much been array indexing. Now, sometimes that has actually been actual
> >> undefined behavior, because it's been overflow in signed variables,
> >> and those are "easy" to find in the sense that you just say "no, can't
> >> do that". UBSAN finds them, and that's good.
> >
> >We build with -fno-strict-overflow, which implies -fwrapv, which removes
> >the UB from signed overflow by mandating 2s complement.
> 
> I am a broken record. :) This is _not_ about undefined behavior.

And yet you introduced CONFIG_UBSAN_SIGNED_WRAP... *UB*san, get it?

> This is about finding a way to make the intent of C authors
> unambiguous. That overflow wraps is well defined. It is not always
> _desired_. C has no way to distinguish between the two cases.

The current semantics are (and have been for years, decades at this
point) that everything wraps nicely and code has been assuming this. You
cannot just change this.

So what you do is do a proper language extension and add a type
qualifier that makes overflows trap and annotate all them cases where
people do not expect overflows (so that we can put the
__builtin_*_overflow() things where the sun don't shine).

And pretty please, also do a qualifier modification extension, because
that's totally painful already.