On Thursday 18 May 2006 18:02, Ingo Molnar wrote: > > * Andi Kleen <ak@xxxxxxx> wrote: > > > The security argument seems quite bogus to me for this because you'll > > never find enough bits to be reasonably secure in the limited 32bit > > space. > > i'm surprised to still see this old (and dangerously misleading) > argument. Even the current limited amount of randomization on i386 is > pretty powerful against certain classes of worms and automated attacks. It just increases their work a bit after they caught up. For a worm 1 or 256 tries is not that big a difference. > > [ randomization on 64-bit would probably be useful against local > attacks too - if we started doing it! But ASLR on x86_64 is in an even > poorer shape than on i386, which is certainly not due to our lack of > trying: see all those rejected patches of x86_64 heap randomization... Hmm? iirc i got a randomization patch from Arjan once which I merged but had to drop then because it caused 32bit failures. I don't remember any other submissions. Much later I re-implemented it in a more complete fashion myself and that's currently in mainline. > But you dont have to believe me - check the exploit templates that > make use of the VDSO page on x86_64. ] You mean the 64bit vsyscalls? Yes, that was a bit poor early design. At some point it has to go over to ELF based, especially when we run out of them (which should happen soon) But I believe i have plugged this hole for most systems. The syscall instructions are noped out for kernels which don't need it for the pmtimer (which is at least all nearly all Intel systems and many AMD systems). And there shouldn't be any other SYSCALL byte combinations in the vsyscall page. I don't know of any other ways to abuse that page without a syscall instruction. The 32bit VDSO is not randomized, but that's the same as native i386. -Andi
