[haiku-development] Re: Fixed main thread user stack address

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 23 Feb 2013 08:41:16 +0100

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

Other related posts: