Date:   Tue, 16 May 2023 13:29:28 -0700
From:   Kees Cook <keescook@...omium.org>
To:     linux-hardening@...r.kernel.org
Cc:     "Gustavo A. R. Silva" <gustavoars@...nel.org>
Subject: Progress on Bounds Checking in C and the Linux Kernel

Hi!

I just wanted to share links to the presentation Gustavo and I gave at
last week's Linux Security Summit. Repeating the abstract here, just so
you don't have to click through if you don't want to:


Linux, like all C code, regularly suffers from heap buffer overflow
flaws. Especially frustrating is that the compiler usually has enough
context to have been able to stop the overflow but has been hampered by
needing to support legacy coding styles, ambiguous language definitions,
and fragile APIs. This has forced the compiler to frequently ignore the
intent of programmers in an effort to support sloppy code patterns that
may not exist in a project at all.

The history of the C language specification's "flex array member" (FAM)
is long and twisty, and technical debt exists due to ambiguous
implementations. With the introduction of -fstrict-flex-arrays, C can
now unambiguously declare array sizes. In the kernel we can build on
this, by transforming trailing zero-length and one-element arrays into
modern C99 FAMs, adding the use of __builtin_dynamic_object_size(),
applying it to defenses like FORTIFY_SOURCE, and expanding where the
compiler can use this knowledge internally for improving existing
sanitizers. Finally, adding a new struct member attribute, we can expand
object size tracking to cover all array types, freeing Linux from this
persistent class of buffer overflows flaws.


Summary: https://lssna2023.sched.com/event/34dfdb61ccf86035c031b5bf2173765a
Slides:  https://outflux.net/slides/2023/lss-na/bounds-checking.pdf

I haven't seen any video published yet, but if that shows up soon, I'll
reply to this thread with a link.

Enjoy! :)

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists