> even forcing 256 tries (which is only 256 in upstream's crippled ASLR, ASLR? > which was crippled partly due to misguided efforts of yours ...) What misguided efforts? > _dramatically_ changes the spreading model of a worm. Frankly, i find it > frustrating having to repeat this simple point so many times during so > many years. This is really not rocket science. Sure but it would be still a very dangerous worm even if it was 128 times slower > i'd suggest for you to somehow start eliminating your apparent phobia Again please read what I wrote: i merged the original simple mmap randomization when it was submitted to me. At least that particular patch had some bug that broke nearly all 32bit programs. Since release was comming up I just dropped it back then. Then nobody sent me patches anymore. After some point I redid it myself, enhancing the common code even to use a large randomization area on 64bit. Don't know where that alleged phobia would come in on that story. > against exec-shield and ASLR in particular. Linux really needs better > ASLR - but it cannot be done without active and willing participation of > architecture maintainers. I cannot comment on that because i still don't know what ASLR is. ok A S is probably address space and R might be randomizaton but the 'L' is mysterious. > there is nothing bad about vsyscalls, and i expect them to be utilized > more in the future. (just think rdtscp) So if you think the problem has > been 'solved' by the apparent temporary non-use of vsyscalls on some > systems, i think you are dangerously wrong again! Correct me if I'm wrong, but afaik the way vsyscalls aide attackers is when they have code at a fixed address with syscall instructions that they can use for their own purposes. The x86-64 vsyscalls used to have that because there is a fallback path for the timer and that used a kernel syscall. It was not normally used, but there so someone evil could jump to it. The way I solved this problem is to nop these bytes out when not needed, so they can't be jumped to (or rather they can, but it won't cause a syscall) To my knowledge all the other code in the x86-64 vsyscall page cannot be abused for any sinister purposes. The i386 vsyscall of course always has syscall code, but that's no different from native i386 and in general the compat layer doesn't try to be better than the original, just compatible. If native i386 randomizes that I wouldn't have a problem with following. -Andi
