[haiku-commits] Re: BRANCH pdziepak-github.aslr - src/system/kernel/vm headers/os/kernel

  • From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 26 Feb 2013 22:47:37 +0100

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ł

Other related posts: