> Kernel.org's view of the tree hasn't updated yet, but I had two patches for > x86-nx-emulation: 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. > http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=cbdd1aea211eb6f69592b4ed0adf3cd46082d016 > http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=232036cd668cdd4f91c4471a3a5d4a0e6a207101 > > The latter one is trivial, the former is the one that Dave extracted from > my original patch to this list. I merged both of those. I was counting the previously-agreed-upon removal of the useless boot parameter as trivial. > Right, I think Ubuntu will be in a similar position eventually. My take on > it is that once 64-bit is considered the default image to be used for new > installs, we'll likely drop the nx-emu patch from the kernel. 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. > > 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.) > > I'm happy to take this on if we're all actually sending commits there. You're the only one who has had any commits for it since I made the branch. So I think "we" are. ;-) > > * 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. > > Do you mean this patch? > http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=70bd5bc09737f450d3cdc86a77d570d3c68980a7 No, I meant c1bf3384, the one you'd sent the pull request for. The 70bd5bc... change goes to the subject below. > So, in my opinion, the ASCII-armor ASLR is bad when compared to > the upstream ASLR. [...] 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. > nx-emu is lower on my list than some of the other features from It's completely off my list, so, rock on. > Well, for the Fedora kernel, it looks like Dave removed my ASLR w/ nx-emu > conditional element. (See urls above.) I'm fine with keeping that patch > out of the tree if we can't agree on it, but I'd like to try to convince > you (Dave? Ingo?) otherwise so we can all have the same patchset. I'd also like you and Dave to agree on something. I don't really care what. Thanks, Roland _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
