From: Kees Cook <keescook@chromium.org>
To: 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-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
Date: Wed, 8 May 2024 15:54:36 -0700 [thread overview]
Message-ID: <202405081354.B0A8194B3C@keescook> (raw)
In-Reply-To: <CAHk-=wjeiGb1UxCy6Q8aif50C=wWDX9Pgp+WbZYrO72+B1f_QA@mail.gmail.com>
On Wed, May 08, 2024 at 01:07:38PM -0700, Linus Torvalds wrote:
> On Wed, 8 May 2024 at 12:45, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> > > Example:
> > >
> > > static inline u32 __hash_32_generic(u32 val)
> > > {
> > > return val * GOLDEN_RATIO_32;
> > > }
> >
> > But what about:
> >
> > static inline u32 __item_offset(u32 val)
> > {
> > return val * ITEM_SIZE_PER_UNIT;
> > }
>
> What about it? I'm saying that your tool NEEDS TO BE SMART ENOUGH to
> see the "what about".
This is verging on omniscience, though. Yes, some amount of additional
reasoning can be applied under certain conditions (though even that would
still require some kind of annotation), but GCC can't even reliably figure
out if a variable is unused in a single function. We're not going to be
able to track overflow tainting throughout the code base in a useful
fashion.
> IOW, exactly the same as "a+b < a". Yes, "a+b" might wrap around, but
> if the use is to then compare it with one of the addends, then clearly
> such a wrap-around is fine.
Yes, but it is an absolutely trivial example: it's a single expression
with only 2 variables. Proving that the value coming in from some
protocol that is passed through and manipulated by countless layers of the
kernel before it gets used inappropriately is not a reasonably solvable
problem. But we can get at the root cause: the language (and our use of
it) needs to change to avoid the confused calculation in the first place.
> A tool that doesn't look at how the result is used, and just blindly
> says "wrap-around error" is a tool that I think is actively
> detrimental.
I do hear what you're saying here. I think you're over-estimating the
compiler's abilities. And as I mentioned in the RFC, finding known bad
cases to protect is the reverse of what we want for coverage: we want
to _not_ cover the things we know to be _safe_. So we want to find
(via compiler or annotation) the cases where overflow is _expected_.
> We already expect a lot of kernel developers. We should not add on to
> that burden because of your pet project.
I think it's a misunderstanding to consider this a pet project. C's lack
of overflow intent has spawned entire language ecosystems in reaction.
There are entire classes of flaws that exist specifically because of this
kind of confusion in C. It is the topic of countless PhD research efforts.
People who care about catching overflows can slowly add the type
annotations over the next many years, and we'll reach reasonable coverage
soon enough. It doesn't seem onerous: I'm not asking that people even
do it themselves (though I'd love the help), I'm just trying to find
acceptance for annotations about where the sanitizer can ignore overflow.
> Put another way: I'm putting the onus on YOU to make sure your pet
> project is the "Yogi Bear" of pet projects - smarter than the average
> bear.
Sure, but if the bar is omniscience, that's not a path forward.
I haven't really heard a viable counterproposal here. Let me try something
more concrete: how would you propose we systemically solve flaws like
the one fixed below? And note that the first fix was incomplete and it
took 8 years before it got fully fixed:
a723968c0ed3 ("perf: Fix u16 overflows") (v4.3)
382c27f4ed28 ("perf: Fix perf_event_validate_size()") (v6.7)
Because the kernel didn't catch when the u16 overflowed, it allowed for
kernel memory content exposure to userspace. And that's just the place
that it got noticed. With the struct holding the u16 is referenced in
360 different source files, it's not always a trivial analysis. But,
for example, the sanitizer not finding a "wraps" annotation on the
perf_event::read_size variable would have caught it immediately on
overflow.
And I mean this _kind_ of bug; not this bug in particular. I'm just
using it as a hopefully reasonable example of the complexity level we
need to solve under.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2024-05-08 22:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 23:27 [RFC] Mitigating unexpected arithmetic overflow Kees Cook
2024-05-08 12:22 ` David Laight
2024-05-08 23:43 ` Kees Cook
2024-05-08 17:52 ` Linus Torvalds
2024-05-08 19:44 ` Kees Cook
2024-05-08 20:07 ` Linus Torvalds
2024-05-08 22:54 ` Kees Cook [this message]
2024-05-08 23:47 ` Linus Torvalds
2024-05-09 0:06 ` Linus Torvalds
2024-05-09 0:23 ` Linus Torvalds
2024-05-09 6:11 ` Kees Cook
2024-05-09 14:08 ` Theodore Ts'o
2024-05-09 15:38 ` Linus Torvalds
2024-05-09 17:54 ` Al Viro
2024-05-09 18:08 ` Linus Torvalds
2024-05-09 18:39 ` Linus Torvalds
2024-05-09 18:48 ` Al Viro
2024-05-09 19:15 ` Linus Torvalds
2024-05-09 19:28 ` Al Viro
2024-05-09 21:06 ` David Laight
2024-05-18 5:11 ` Matthew Wilcox
2024-05-09 21:23 ` David Laight
2024-05-12 8:03 ` Martin Uecker
2024-05-12 16:09 ` Linus Torvalds
2024-05-12 19:29 ` Martin Uecker
2024-05-13 18:34 ` Kees Cook
2024-05-15 7:36 ` Peter Zijlstra
2024-05-15 17:12 ` Justin Stitt
2024-05-16 7:45 ` Peter Zijlstra
2024-05-16 13:30 ` Kees Cook
2024-05-16 14:09 ` Peter Zijlstra
2024-05-16 19:48 ` Justin Stitt
2024-05-16 20:07 ` Kees Cook
2024-05-16 20:51 ` Theodore Ts'o
2024-05-17 21:15 ` Kees Cook
2024-05-18 2:51 ` Theodore Ts'o
2024-05-17 22:04 ` Fangrui Song
2024-05-18 13:08 ` David Laight
2024-05-15 7:57 ` Peter Zijlstra
2024-05-17 7:45 ` Jonas Oberhauser
2024-05-11 16:19 ` Dan Carpenter
2024-05-13 19:43 ` Kees Cook
2024-05-14 8:45 ` Dan Carpenter
2024-05-18 15:39 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202405081354.B0A8194B3C@keescook \
--to=keescook@chromium.org \
--cc=justinstitt@google.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).