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: <20240516205134.GC287325@mit.edu>
Date: Thu, 16 May 2024 14:51:34 -0600
From: "Theodore Ts'o" <tytso@....edu>
To: Justin Stitt <justinstitt@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Kees Cook <kees@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>, 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 12:48:47PM -0700, Justin Stitt wrote:
> 
> It is incredibly important that the exact opposite approach is taken;
> we need to be annotating (or adding type qualifiers to) the _expected_
> overflow cases. The omniscience required to go and properly annotate
> all the spots that will cause problems would suggest that we should
> just fix the bug outright. If only it was that easy.

It certainly isn't easy, yes.  But the problem is when you dump a huge
amount of work and pain onto kernel developers, when they haven't
signed up for it, when they don't necessarily have the time to do all
of the work themselves, and when their corporate overlords won't given
them the headcount to handle unfunded mandates which folks who are
looking for a bright new wonderful future --- don't be surprised if
kernel developers push back hard.

One of the big problems that we've seen with many of these security
initiatives is that the teams create these unfunded mandates get their
performance reviews based on how many "bug reports" that they file,
regardless of whether they are real problems or not.  This has been a
problem with syzkaller, and with clusterfuzz.  Let's not make this
problem worse with new and fancy sanitizers, please.

Unfortunately, I don't get funding from my employer to clear these
kinds of reports, so when I do the work, it happens on the weekends or
late at night, on my own time, which is probably why I am so grumpy
about this.  Whether you call this "sharpening our focus", or "year of
efficiency", or pick your corporate buzzwords, it really doesn't
matter.  The important thing is that the figure of merit must NOT be
"how many security bugs that are found", but how much bullsh*t noise
do these security features create, and how do you decrease overhead by
upstream developers to deal with the fuzzing/ubsan/security tools
find.

Cheers,

						- Ted