Well, the existing ASLR infrastructure is actually pretty good -- if
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
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
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:
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.
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.