Pawel Dziepak wrote: > 2013/2/22 Ingo Weinhold <ingo_weinhold@xxxxxx>: > ASLR wastes virtual address space, it is inevitable. All attempts to > reduce fragmentation or in general make ASLR less wasteful would > result in ASLR being weaker. It is just a matter of compromise. I have > been (and still am) checking other implementations of ASLR in search > for some ideas how to waste less memory but mostly they do not really > care. Apparently in practice it does not turns out to be a big > problem. I believe other systems aren't as thread-happy as Haiku. E.g. one problem on BeOS was that you couldn't open more than about 100 windows, because the app server wouldn't be able to create the stacks for the required threads due to running out of address space for them. Haiku's address space layout is more intelligent, so we don't run into that issue. But if you start to randomly distribute the stacks for the threads over the address space, it's likely you'll get quite a bit of address space fragmentation over time. I think this definitely is something to keep in mind. > Fortunately this problem virtually does not exist on 64 bit > architectures since there is plenty of virtual address space to waste. Yeah, I guess ASLR is an R2 feature anyway. ATM there's really little point in having/activating it. > > Other than that the commpage is at a fixed address and randomizing it may > > not be trivial. There's also the team user data area. It should be easy to > > move, but it need some pages of room so it can grow, if many threads are > > created. > > AFAIK only libroot accesses commpage directly so it should not break > ABI making its position non-deterministic (and no need for solutions > like vdso and vsyscall in Linux). It probably would require more work > than other things that are going to be shuffled but there will not be > any complicated compatibility-related problem with no good solutions. No, there won't be any compatibility issues. I was only referring to the ease of changing it. CU, Ingo