LWN: Comments on "Cook: Security things in Linux v4.13"

Cook: Security things in Linux v4.13

paulj — Sun, 24 Sep 2017 12:45:10 +0000

If PaxTeam also refers to Brad, then I don't believe your statement is true. Brad Spengler /did/ try to upstream his work, for a good while. He got flamed to a crisp for it by Linus eventually, and repeatedly IIRC.

Cook: Security things in Linux v4.13

dirtyepic — Mon, 11 Sep 2017 18:45:22 +0000

Several of the GCC hardening flags are enabled by default in Gentoo.

Cook: Security things in Linux v4.13

ledow — Sun, 10 Sep 2017 14:47:18 +0000

PaXTeam have never showed the slightest inclination at working with the kernel team to include their work piecemeal, as is required.

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.

Cook: Security things in Linux v4.13

thestinger — Fri, 08 Sep 2017 07:10:50 +0000

> I really hope this will be part of the compiler and work for all software (yet another warning :-P).

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

ntnn — Fri, 08 Sep 2017 05:08:38 +0000

You can use the hardened profile without using the hardened kernel.

Cook: Security things in Linux v4.13

Tara_Li — Thu, 07 Sep 2017 16:26:36 +0000

I'll have to look into how to enable this for Gentoo at some point, so I can get the benefits.

Cook: Security things in Linux v4.13

flussence — Thu, 07 Sep 2017 16:09:58 +0000

>Perhaps Brad and company were not offered the same opportunity for the constant belittle and finger pointing at upstream? Or their childish name calling non-stop.
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

SEJeff — Thu, 07 Sep 2017 13:50:10 +0000

Perhaps Brad and company were not offered the same opportunity for the constant belittle and finger pointing at upstream? Or their childish name calling non-stop.

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.

Cook: Security things in Linux v4.13

pabs — Thu, 07 Sep 2017 13:14:04 +0000

> I really hope this will be part of the compiler and work for all software

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.

Cook: Security things in Linux v4.13

patrick_g — Thu, 07 Sep 2017 12:50:37 +0000

> I always wondered if they really wanted to improve the security

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.

Cook: Security things in Linux v4.13

ovitters — Thu, 07 Sep 2017 12:41:44 +0000

I'm quite pleased that all of these security improvements are being made. It's rather unfortunate the way that PAX handled things. I always wondered if they really wanted to improve the security especially due to their recent actions (keeping their patches private, trying to force customers not to share them, etc).

> 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).