Cook: Security things in Linux v4.13
Daniel Micay created a version of glibc’s FORTIFY_SOURCE compile-time and run-time protection for finding overflows in the common string (e.g. strcpy, strcmp) and memory (e.g. memcpy, memcmp) functions. The idea is that since the compiler already knows the size of many of the buffer arguments used by these functions, it can already build in checks for buffer overflows. When all the sizes are known at compile time, this can actually allow the compiler to fail the build instead of continuing with a proven overflow. When only some of the sizes are known (e.g. destination size is known at compile-time, but source size is only known at run-time) run-time checks are added to catch any cases where an overflow might happen. Adding this found several places where minor leaks were happening, and Daniel and I chased down fixes for them."
Posted Sep 7, 2017 12:41 UTC (Thu)
by ovitters (guest, #27950)
[Link] (10 responses)
> When all the sizes are known at compile time, this can actually allow the compiler to fail the build instead of continuing with a proven overflow.
I really hope this will be part of the compiler and work for all software (yet another warning :-P).
Posted Sep 7, 2017 12:50 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (4 responses)
To play the Devil's advocate, Kees is paid by Google to do this work. According to Brad and PaXTeam they were never offered the same opportunity.
Posted Sep 7, 2017 13:50 UTC (Thu)
by SEJeff (guest, #51588)
[Link] (1 responses)
Sure they write great code, but if only a select few users can use it, how good is what they're really doing? Comparatively, Kees and the KSP (Kernel Self Protection) project have been breaking up a lot of their ideas and getting them merged upstream, where they benefit the literally millions of Linux users, vs the few that use the grsec patched kernels. Additionally, some of the features in the KSP are independent of the grsecurity / PAX patchsets.
Posted Sep 7, 2017 16:09 UTC (Thu)
by flussence (guest, #85566)
[Link]
Posted Sep 10, 2017 14:47 UTC (Sun)
by ledow (guest, #11753)
[Link] (1 responses)
They have a superiority complex which leads them to believe everyone should just dump their megabytes of patches direct into the kernel without oversight, control or audit.
So it's not really surprising that they were overlooked in preference to others.
Don't forget - just because Google sponsor it doesn't mean that anyone will let it into the kernel no matter what state it's in. And if you're going to sink money on someone on a project intending to get stuff into the official kernel, then PaX basically has zero comparative experience compared to a lot of other people who could do the work.
Posted Sep 24, 2017 12:45 UTC (Sun)
by paulj (subscriber, #341)
[Link]
Posted Sep 7, 2017 13:14 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (3 responses)
GCC upstream doesn't enable the hardening flags by default, so you either have to be on a distro that forces them on by default, or passing hardening flags to every build. Some distros choose the latter option, which means non-distro binaries usually do not have hardening flags applied.
Posted Sep 7, 2017 16:26 UTC (Thu)
by Tara_Li (guest, #26706)
[Link] (2 responses)
Posted Sep 8, 2017 5:08 UTC (Fri)
by ntnn (guest, #109693)
[Link]
Posted Sep 11, 2017 18:45 UTC (Mon)
by dirtyepic (guest, #30178)
[Link]
Posted Sep 8, 2017 7:10 UTC (Fri)
by thestinger (guest, #91827)
[Link]
For userspace, it's a libc feature that has existed for many years. No need to wait to have it outside the kernel.
This new kernel implementation of FORTIFY_SOURCE is different than in glibc since it checks for read overflows in addition to write overflows while glibc only adds checks for writes. The kernel implementation doesn't yet offer an equivalent to _FORTIFY_SOURCE=2 (intra-object overflow checks) in glibc in Linux 4.13 but the option exists downstream and is being actively tested already. The kernel implementation also works with both GCC and Clang, while the glibc implementation only works with GCC. Bionic used to have an implementation that worked with both GCC and Clang, but they're dropping GCC support and moved to a superior mechanism only available to Clang.
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
There's no perhaps about it. They conducted themselves as horribly as possible in public for 10+ years, then had the audacity to demand to be paid tribute from anyone with deep pockets who ever used their patches, throwing the rest of their users under the bus out of spite as if it'd accomplish anything. Nobody would want their organisation's name tainted with that kind of association.
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13
Cook: Security things in Linux v4.13