2013/2/26 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>: > Am 25/02/2013 23:00, schrieb pdziepak-github.aslr: > >> +/* http://graphics.stanford.edu/~seander/bithacks.html */ >> +static int >> +log2(uint32_t v) > > The scheduler is already using its own random function; maybe it makes sense > to put that all into some utility code. > Besides that, we keep the methods in declaration order, and keep class > methods together; IOW that helper functions should go to some place before > the class methods. I am afraid it is not that easy. Scheduler indeed uses its own pseudorandom number generator (and, according to OpenGrok, defines the same function four times) which is fast but weak. That is OK for scheduler, but not OK for ASLR since it needs more cryptographically secure pseudorandom number generator (even if it would be slower than the one used by the scheduler). That's why it currently uses stronger stdlib version of rand(), which also is not good enough. I intended to address that issue later, after implementing ASLR and use either something similar to the PRNG Linux uses it its ASLR or yarrow RNG. Nevertheless, there is not point in making scheduler and ASLR use the same PRNG since they have different requirements. I will leave it as it is for now (except from moving log2() to the top of the file). >> + if (addressSpec == B_RAND_BASE_ADDRESS) { >> + originalStart = start; >> + start = _RandomizeAddress(start, end - size, true); >> + } >> + >> start = ROUNDUP(start, alignment); > > > I don't see where you change the size requirements of areas with a > randomized start pointer - it might need a page more. _RandomizeAddress randomizes address with page granularity so that there is no reason to adjust the area size. Inside the page randomization is only performed in special cases and is not handled here (like initial stack pointer randomization from previous commit). Paweł