Messages in this thread | | | Date | Thu, 16 Dec 2021 11:21:56 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time |
| |
On Thu, Dec 16, 2021 at 11:08:26AM +0000, Mark Rutland wrote: > On Mon, Dec 13, 2021 at 02:33:20PM -0800, Kees Cook wrote: > > memcpy() is dead; long live memcpy() > > > > tl;dr: In order to eliminate a large class of common buffer overflow > > flaws that continue to persist in the kernel, have memcpy() (under > > CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct > > member when they have a known size. This would have caught all of the > > memcpy()-related buffer write overflow flaws identified in at least the > > last three years. > > > > Hi Kees, > > Since there's a *lot* of context below, it's very easy to miss some key details > (e.g. that the compile-time warnings are limited to W=1 builds). It would be > really nice if the summary above could say something like: > > This patch makes it possible to detect when memcpy() of a struct member may > go past the bounds of that member. When CONFIG_FORTIFY_SOURCE=y, runtime > checks are always emitted where the compiler cannot guarantee a memcpy() is > safely bounded, and compile-time warnings are enabled for W=1 builds. > > This catches a large class of common buffer overflow flaws, and would have > caught all of the memcpy()-related buffer write overflow flaws identified in > the last three years. > > As an aside, since W=1 is chock-full of (IMO useless) warnings, is there any > way to enable *just* the FORTIFY_SOURCE warnings? > > [...] > > > Implementation: > > > > Tighten the memcpy() destination buffer size checking to use the actual > > ("mode 1") target buffer size as the bounds check instead of their > > enclosing structure's ("mode 0") size. Use a common inline for memcpy() > > (and memmove() in a following patch), since all the tests are the > > same. All new cross-field memcpy() uses must use the struct_group() macro > > or similar to target a specific range of fields, so that FORTIFY_SOURCE > > can reason about the size and safety of the copy. > > > > For now, cross-member "mode 1" read detection at compile-time will be > > limited to W=1 builds, since it is, unfortunately, very common. As the > > priority is solving write overflows, read overflows can be part of the > > next phase. > > I had a go at testing this on arm64, and could get build-time warnings from GCC > 11.1.0, but not from Clang 13.0.0.
Looking again, I see this is down to __compiletime_warning() only being usable from clang 14.0 onwards (and the final patch mentions that in passing), so I guess that's expected.
It would be nice to call that out somewhere in this patch (e.g. in that introductory paragraph), since it's very each to miss that and get confused... ;)
Thanks, Mark.
| |