The 4.6 kernel has been released
It's just as well I didn't cut the rc cycle short, since the last week ended up getting a few more fixes than expected, but nothing in there feels all that odd or out of line." Some of the more significant changes in this release are: post-init read-only memory as a bare beginning of the effort to harden the kernel, support for memory protection keys, the preadv2() and pwritev2() system calls, the kernel connection multiplexer, the OrangeFS distributed filesystem, compile-time stack validation, the OOM reaper, and many more. See the KernelNewbies 4.6 page for an amazing amount of detail.
(Log in to post comments)
The 4.6 kernel has been released
Posted May 16, 2016 7:08 UTC (Mon) by torquay (guest, #92428) [Link]
Greg KH says:-
The new release that's going to come out next week has write-only protection to all the data structures. If something happens and you can't override a data structure, you can't. All of a sudden we took out a whole class of exploits that a bug could turn into an exploit.
-
A quick grep through our latest patch shows we're using this marking on about 200 global variables and data structures important to the kernel's security. In the to-be-released Linux 4.6, this feature protects exactly *one* thing (...) the bare minimum effort required to claim support for X and publish an entire PR piece about it.
The 4.6 kernel has been released
Posted May 16, 2016 7:09 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
The 4.6 kernel has been released
Posted May 16, 2016 8:00 UTC (Mon) by ledow (guest, #11753) [Link]
https://lwn.net/Articles/686341/
I find it really frustrating that the guy can't just suck it up, get out of "I told you so" mode, and just package his patches up for inclusion like an adult. He's obviously talented, but it's so vastly obscured that it's talent nobody wants to deal with.
The 4.6 kernel has been released
Posted May 16, 2016 16:42 UTC (Mon) by Lionel_Debroux (subscriber, #30014) [Link]
But some of the most powerful defenses in PaX/grsec, namely UDEREF and KERNEXEC, are refused for upstreaming, because ~"the hardware now does it". Never mind the facts that they work on processors over a decade old instead of a small subset of very recent processors (x86_64 SMEP+SMAP is pretty new, as are ARM/ARM64 PAN), and that UDEREF+KERNEXEC provide a strict superset of the x86_64 SMEP+SMAP functionality. PaXTeam has been posting this time and again...
I shudder to think about mainlining of RANDSTRUCT and RAP. As shown by CONSTIFY, it's very hard to get small scattered fixes and improvements (here, casts between fptrs of different type and C99 designated initializers) in mainline. Dozens of hunks of PaX/grsec have been unchanged for years...
AFAICT, spender and PaXTeam would rather use their time on research and hardening - and there's still much to do in that area - than on politics.
The 4.6 kernel has been released
Posted May 16, 2016 20:41 UTC (Mon) by jubal (subscriber, #67202) [Link]
AFAICT, spender and PaXTeam would rather use their time on research and hardening - and there's still much to do in that area - than on politics.Pity that they do feel the need to communicate with the world with the style and gusto of permanently irritated thirteen-year-olds instead…
The 4.6 kernel has been released
Posted May 17, 2016 5:48 UTC (Tue) by Lionel_Debroux (subscriber, #30014) [Link]
Every day, the hard work of (mainly) Brad "spender" Spengler, PaXTeam ("pipacs" on IRC) and Emese "ephox" Revfy is being decried, minimized, misattributed by hordes of incompetents who think they have a clue. Said hard work is a very long stream of ground-breaking, effective defenses, invented over more than 15 years - as a part-time job !
Meanwhile, security of mainline Linux barely progresses over time:
* powerful defenses, not just UDEREF and KERNEXEC, are outright rejected for bad reasons;
* only a small subset of the known good defenses is added, very slowly and not even always the right way: I recently read about the mainline memory sanitization as both more complicated and less powerful than that of grsec; also, the way __ro_after_init is being added to the kernel is a thoroughly sick joke, as outlined by alonz and minipli below, and public communication about it is outright misleading and wrong;
* bad defenses are being added and take resources away from the more efficient stuff: PaX/grsec do not implement KASLR because it has low protective value by itself and multiple known defeats (spender posted about a defeat with <300-byte source code which can run in a seccomp mode 1 sandbox, not to mention the many infoleaks in mainline not plugged by e.g. stack sanitization;
* brand-new security pigs, as proven after the fact by their track record, enter the mainline kernel on a frequent basis: BPF JIT, unprivileged user namespaces (a treasure for privilege escalation), etc. Needless to say, grsec either hardens, or outright disables, the pigs.
The size of the grsecurity patch more than quadrupled over the past five years and doubled over the past two years: grsecurity-2.2.2-3.0.3-201108232250.patch is 2291624 bytes, grsecurity-3.0-3.14.10-201407012152.patch is 4106385 bytes, grsecurity-3.1-4.5.4-201605131918.patch is 9091528 bytes. Years ago, before CONSTIFY was rewritten, I spent a bit of time pushing to mainline several tiny bits of the low-hanging fruit, but I have other (user-space) things to focus on, and mainline feels like a bottomless pit.
The 4.6 kernel has been released
Posted May 18, 2016 21:35 UTC (Wed) by nix (subscriber, #2304) [Link]
The 4.6 kernel has been released
Posted May 17, 2016 7:33 UTC (Tue) by ledow (guest, #11753) [Link]
UDEREF: from the man himself: https://lwn.net/Articles/342751/ (also read: https://grsecurity.net/~spender/uderef.txt - it's hardly a panacea and more a software stop-gap that can be bypassed)
Though I don't disagree this stuff would be useful, the sheer amount of time spent on it and the complete lack of results getting it committed show that there's something wrong here.
And all that I find on actually submitting this stuff doesn't go anywhere near as far as other contributors unless - and I can find these - other contributors do the submission work for PaX/grsecurity - breaking it up, isolating features, testing and posting patches piecemeal. Instead I see attitudes like: http://unix.stackexchange.com/questions/59020/why-are-the...
(Quote from that: "We've never submitted the patches for mainline inclusion. One simple reason is that we're the ones with the ideas and implementations, which upstreaming would not solve." - so as of 2012 they hadn't been trying for inclusion, and you can just feel the attitude).
My searches are also sadly lacking in hits on the linux-kernel mailling lists which, last time I looked, were the places that patches and pull requests actually end up? Maybe it's Google being biased in the modern age but I see more articles about how it isn't in than I do see patches, or patch attempts, or git-pull requests, etc.
And, given previous conversations on here with the guy himself, I'm not entirely convinced that this impression of their cooperation is in any way unfair.
The 4.6 kernel has been released
Posted May 17, 2016 10:21 UTC (Tue) by Lionel_Debroux (subscriber, #30014) [Link]
Well, the fact that this very website has an article from 2012 about SMAP does not mean that Intel processors with the SMAP feature have been available for purchase in the real world, ever since 2012 :)
Haswell processors from 2013 and 2014 do not have SMAP. I know from other sources, and anyway, I have access to two models of computers equipped with Haswell processors: i7-4700HQ from 2013 and i5-4590 from 2014, neither of which has SMAP. Only the relatively short-lived Broadwell (2014, for most purposes 2015), and the longer-lived Skylake (2015 to present) processor - i.e. the two latest generations of higher-powered processors from Intel - have it. Two years later than the article you're pointing.
Contrast that with a protection which works on a wide range of Intel, AMD and compatible x86/x86_64 processors, because it does not _need_ special hardware support (though it can leverage e.g. PCID and INVPCID for greater speed and/or protection for UDEREF), and has been available for a decade (!) before SMAP hit the market. Likewise, ARM PAN is newer, and has narrower hardware support, than UDEREF on ARM.
In the sea of x86/x86_64 devices used in the real world today, Broadwell and Skylake are a small minority. Hence my "a small subset of very recent processors" claim, which I stand behind, based on the above facts.
> UDEREF: from the man himself: https://lwn.net/Articles/342751/ (also read: https://grsecurity.net/~spender/uderef.txt - it's hardly a panacea and more a software stop-gap that can be bypassed)
You can find more contemporary quotes from the man himself, indicating that SMAP is functionally still a strict subset of UDEREF, and that it could be turned into something more useful.
I know UDEREF is not perfect, I didn't state it is - it "just" protects way more computers than SMAP does :)
The CONSTIFY mainline submission by Emese Revfy was a 100+-patch series.
I don't think either of us is going to convince the other one where the main part of the uncooperativeness and attitude problem lies, so how about we stop discussing on that angle ?
The 4.6 kernel has been released
Posted May 17, 2016 11:33 UTC (Tue) by spender (guest, #23067) [Link]
-Brad
The 4.6 kernel has been released
Posted May 16, 2016 13:16 UTC (Mon) by k3ninho (subscriber, #50375) [Link]
"Yay for more kernel self-protection! (The article[2] is a little hard to parse: the details on the security improvements read like it's been through several translations.) The primary take-away continues to be: you MUST design systems that update their kernels. (Note that the prerequisite for being able to update kernels is that all the code needed for your system MUST be upstream.)
"As for security features I've been tracking in 4.6:
- KASLR on arm64 (though requires the bootloader to provide entropy)
- Kernel memory protection by default on ARMv7+
- Kernel memory protection by default on arm64
- Kernel memory protection mandatory on x86
- __ro_after_init markings for write-once data
"For 4.7, I think it's likely we'll see:
- split of physical/virtual text base address randomization for x86 KASLR
- KASLR on MIPS
- LoadPin LSM to control kernel module and firmware origins
"For 4.8, I'm hoping we'll see:
- randomization of base addresses for page tables, vmalloc, and other memory regions for x86 KASLR
- gcc plugin infrastructure
- per-build structure layout randomization"
1: https://plus.google.com/+KeesCook/posts/adtf8msMKNL
2: https://www.linux.com/news/greg-kh-update-linux-kernel-46...
K3n.
The 4.6 kernel has been released
Posted May 16, 2016 14:58 UTC (Mon) by hitmark (guest, #34609) [Link]
The 4.6 kernel has been released
Posted May 16, 2016 18:08 UTC (Mon) by alonz (subscriber, #815) [Link]
Actually spender is simply right, in this case – __ro_after_init is only used in a single place in the entire 4.6 kernel (for protecting the VDSO).There's still significant low-hanging fruit left to be done here; at a minimum, marking various "_ops" / "_fns" structs (tables of functions) as __ro_after_init.
The 4.6 kernel has been released
Posted May 16, 2016 20:38 UTC (Mon) by minipli (guest, #69735) [Link]
That's what I'd call security circus -- just marking a checkbox and moving on to the next one -- without actually caring about "security".
The 4.6 kernel has been released
Posted May 18, 2016 21:34 UTC (Wed) by nix (subscriber, #2304) [Link]
(The real problem here is a lack of follow-through, not that the initial act was a bad one.)
The 4.6 kernel has been released
Posted May 18, 2016 21:52 UTC (Wed) by minipli (guest, #69735) [Link]
Improving kernel self-protection
Posted May 16, 2016 20:51 UTC (Mon) by david.a.wheeler (guest, #72896) [Link]
It's true that working together with a larger community is difficult, and it can indeed slow things down. However, if often produces better and more wide-spread results. I think Kees' kernel self-protection work is exactly what's needed - let's get improvements developed in various places into the kernel that most people use.
The 4.6 kernel has been released
Posted May 17, 2016 10:47 UTC (Tue) by tao (subscriber, #17563) [Link]