On Fri, Oct 29, 2010 at 08:41:40AM -0700, Kees Cook wrote: ... Because this is a Fedora kernel package git tree, not a kernel git tree. Dave added it to the Fedora kernel package, so he's the author. Note the kernel.spec changelog entry. -- Jarod Wilson jarod(a)redhat.com

Let's address the two branches separately, since they have different issues and are only slightly related at this point. I'm well past ready to be done thinking about this stuff. If you and Dave agree on the details, then I'm happy to be out of the loop in the future. * x86-nx-emulation I merged your trivia patch, and then rebased the branch on v2.6.36, since that's what rawhide currently starts from. We seem to think this one will never have a chance of going upstream. Its only use is for hardware that has been obsolete for some years now. I imagine one day we'll drop it from Fedora when that hardware is no longer of concern (though that may well be some more years off). If there is to be a canonical git branch for this in the future, I'm happy to have it be the one you maintain. I'll let Dave and Kyle decide how to deal with that for Fedora. (Using a single rpm patch that is the whole branch diff makes sense to me.) * 32bit-mmap-exec-randomization Your patch's comment says "in the case of NX emulation", but this has nothing directly to do with that. So that comment is just confusing in an area that's already too complex for anyone to keep track of. Ingo says this stuff is worthwhile for any 32-bit platform. Lacking it makes NX emulation especially useless, but that doesn't mean this code is "for NX emulation". IMHO it should be upstreamed, with whatever reworking is required for that. But Ingo has never really responded usefully about that. I don't see any rationale for this to be carried forever in distros without getting resolved upstream. I'd be willing to help with the reworking if there is some real engagement upstream about getting it resolved. But I have no interest in arguing for or about it. The brk fix takes this farther in the direction of kludginess that seems unlikely to fit how a clean reworking for upstream would be done. Given the kludgey nature of the whole branch, it's not drastically worse, and is a fix for a real problem. I don't understand why your fix should only apply to 32-bit kernels, since the rest of the branch treats 32-bit processes the same on both 64-bit and 32-bit kernels. My first choice would be that you and Ingo work this out in a way that upstream can accept. In the interim for Fedora, I'd rather see this change with a comment that is not misleading, and with some resolution to the question of why you applied the fix only on 32-bit kernels. But I don't really care any more. Since Dave already took your patch as it is, whatever details you work out with him are OK by me. Thanks, Roland

It seems to take an unpredictable interval between one minute and ~30 minutes for the anonymous git.kernel.org trees to update. I'm sure you can get a kernel.org account if you ask, and ssh://master.kernel.org/ URLs (replacing git://git.kernel.org/) have the real stuff immediately. I merged both of those. I was counting the previously-agreed-upon removal of the useless boot parameter as trivial. My take on it is that nobody who really cares about the security benefits of PROT_EXEC enforcement would actually use hardware so old, the kind of people who just think they care but don't really care are the same kind of people who would fail to use a PAE kernel and not realize that means they couldn't use NX on modern hardware anyway, so we really might as well just punt it already. But my meta-take on it is that I have less than zero interest in convincing anybody of anything about this subject. You're the only one who has had any commits for it since I made the branch. So I think "we" are. ;-) No, I meant c1bf3384, the one you'd sent the pull request for. The 70bd5bc... change goes to the subject below. I have no particular opinions about that stuff. I'd like to see you and Ingo (and anyone else who cares) work out a mutually-agreed solution and have that upstream. (Note that AFAIK Ingo is not on this list). If that consensus is that what's already upstream is as good as it should be, then I'd be glad to see this dropped from Fedora. My weak opinion is that it seems bad for the randomization details to depend on whether the hardware has NX support (or, indeed, whether the hardware is 64-bit or 32-bit). Having every 32-bit process around the world behave consistently makes things easier for debugging user issues, predictability (of the range of randomness), etc. But the aforementioned consensus being achieved regardless of that opinion of mine is what I think is most important. It's completely off my list, so, rock on. I'd also like you and Dave to agree on something. I don't really care what. Thanks, Roland

On Mon, Nov 08, 2010 at 05:34:09PM -0800, Kees Cook wrote: To be honest, I share Rolands apathy about the whole thing. I've not had a response about this stuff from Ingo about it, so I've pretty much just given up on it. As of last month, I don't even have any 32-bit only boxes, so I care even less about any of this than I did before. Dave

On Tue, Nov 09, 2010 at 09:48:03AM -0800, Kees Cook wrote: sounds ok to me. On the subject of randomisation, this article.. http://labs.mwrinfosecurity.com/notices/assessing_the_tux_strength_part_2... bugged me. Notably the discrepancy between Fedora and everyone else on the shlib test. I didn't get around to testing whether this was a side-effect of the ascii-armor patch. I also couldn't reproduce the results the article author noted, on 32bit or 64bit, but iirc, it was still lower than the results for everyone else. any ideas for what could be the cause ? Dave

On Tue, Nov 09, 2010 at 10:54:51AM -0800, Kees Cook wrote: Actually, in looking at paxtest, it's reporting correctly. I'm not sure what other patches are in the Fedora kernel, but it seems like while Ubuntu's entropy with ascii-armor aslr is bad, Fedora's is even worse. Fedora 13: $ for i in $(seq 1 1000); do cat /proc/self/maps | grep 'x.*/lib/.*libc'; done | sort | uniq -c | sort -n 110 00110000-00296000 r-xp 00000000 fd:00 97601 /lib/libc-2.12.so 890 00904000-00a8a000 r-xp 00000000 fd:00 97601 /lib/libc-2.12.so Ubuntu 10.04: $ for i in $(seq 1 1000); do cat /proc/self/maps | grep 'x.*/lib/.*libc'; done | sort | uniq -c | sort -n ...[768 lines of differing addresses]... 3 00de3000-00f36000 r-xp 00000000 fb:01 130850 /lib/tls/i686/cmov/libc-2.11.1.so 174 00110000-00263000 r-xp 00000000 fb:01 130850 /lib/tls/i686/cmov/libc-2.11.1.so -- Kees Cook Ubuntu Security Team

Hi Ingo, On Wed, Nov 10, 2010 at 09:00:10AM +0100, Ingo Molnar wrote: Yeah, that's why I replicated it externally, just to allay any fears about paxtest itself. -Kees -- Kees Cook Ubuntu Security Team

* Dave Jones <davej(a)redhat.com&gt; wrote: Well, Linus & co NAK-ed the 'ia32emu' bits years ago rather forcefully, so you guys need to raise it with him and Andrew - those patches touch the MM. Might be worth an attempt on lkml - but chances are high that you'll get a 'bleh' again. Those vma tracking bits are not nice, they are a linear list walk in some cases. Thanks, Ingo