> Well, the existing ASLR infrastructure is actually pretty good -- if we > could eke out even more entropy that'd be nice. One of our ARM kernel guys > just recently finished up getting ASLR working there, and that'll be > getting upstreamed soon. Ingo says the important point of the PROT_EXEC handling is to choose a 32-bit address that has some whole byte of 0. > Git confuses me to no end. Is my branch not on Linus's HEAD? At the moment Linus's HEAD is v2.6.35-rc5, so no, it's not. It's on v2.6.35-rc3-262-g984bc96, which was Linus's HEAD two weeks ago. It's some git mystery I also don't follow why the ... log syntax doesn't look clean. But upstream..kees/nx-emu does look clean. So go figure. Ra ra git. Anyway, if you're trying to keep it a simple history, a fresh 'git rebase' should do it. > Ah, yeah, that's where I was looking -- I prefer to use the upstream ASLR > when we don't have to pin the libraries in the "below 0x08000000" range. > I.e. we only use the weaker ASLR when we're forced to use the nx-emu too. Ingo's plan is intended to be "better" because having a 0 byte in the address is inherently helpful for defanging exploits in a qualitative sense different from simple measurement of how much randomness there is in the address selection. It is not related to NX emulation. When NX emulation is actually taking place, it's furthermore desireable to put all PROT_EXEC mappings at addresses lower than all non-PROT_EXEC mappings. So that (i.e. !(__supported_pte_mask & _PAGE_NX) tests) could perhaps influence what randomization details you want to use. But that is really the secondary concern for us. > > but I'd like it better if you started from our current two patches instead. > > ;-) > > Sure, I can do that -- do you want to push a git tree with those patches, > and I can work off that and send you stuff to merge? Frankly, I'm more interested in you and Ingo agreeing on new randomization behavior for executable mappings and seeing if we can't get that (or at least configurability that makes it an option) in upstream. But since you asked and it was easy: git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland.git Two branches: fedora/x86-nx-emulation Ingo thinks this will never go upstream. That being the case, it's more or less fine as it stands. The only cleanup it really needs is to replace the exec-shield sysctl/boot parameter with something more sensically named. The only function of it is to suppress the NX emulation on a machine that would otherwise do it (i.e. has no NX). Changing the sysctl only affects new processes, since it just causes "arch_add_exec_range(current->mm, -1);". But disabling this at boot time means it can leave sysenter enabled, which exec-shield=0 now does. Once you've done that, you can't really usefully enable the sysctl later, since you'll still be using sysenter, which breaks the segmentation every time. So perhaps you should not be able to reenable it by sysctl at all. I don't really know why anyone might want to disable it, except for bugs in it. So it probably doesn't matter much what knobs we leave here. But the current one is stupid. fedora/32bit-mmap-exec-randomization This can probably do with being rewritten from scratch, in fact. I said before that I think the clean change, and the approach that I'd prefer if I were upstream, is to just adjust the get_unmapped_area function and hooks throughout to take the prot argument, rather than adding the second hook. Whatever the cleaned-up version of executable mapping logic is, it really belongs in a generic version of the function, it's desireable for any 32-bit process. We should do a little jiggery so that sys_x86_64.c's function can call that generic code instead of duplicating it wholesale by cut&paste as it is now. If you and Ingo can agree on what the actual address selection algorithm should be for 32-bit PROT_EXEC mappings, I can be talked into doing all the glue and cleanup juggling around it. Thanks, Roland _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
