From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: linux-hardening@vger.kernel.org
Subject: Re: Progress on Bounds Checking in C and the Linux Kernel
Date: Thu, 25 May 2023 12:40:48 -0600 [thread overview]
Message-ID: <ZG+rsFgyQ1R0/ypG@work> (raw)
In-Reply-To: <202305161325.0E3BF912@keescook>
On Tue, May 16, 2023 at 01:29:28PM -0700, Kees Cook wrote:
> 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.
The video is finally out: https://www.youtube.com/watch?v=V2kzptQG5_A
Thanks
--
Gustavo
prev parent reply other threads:[~2023-05-25 18:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 20:29 Progress on Bounds Checking in C and the Linux Kernel Kees Cook
2023-05-25 18:40 ` Gustavo A. R. Silva [this message]
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=ZG+rsFgyQ1R0/ypG@work \
--to=gustavoars@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.