On Mon, Aug 7, 2017 at 12:12 PM, Kees Cook <keescook@xxxxxxxxxx> wrote:
On Mon, Aug 7, 2017 at 12:05 PM, Kostya Serebryany <kcc@xxxxxxxxxx> wrote:
>
>
> On Mon, Aug 7, 2017 at 11:59 AM, Kees Cook <keescook@xxxxxxxxxx> wrote:
>>
>> On Mon, Aug 7, 2017 at 11:56 AM, Kostya Serebryany <kcc@xxxxxxxxxx> wrote:
>> > Is it possible to implement some userspace<=>kernel interface that will
>> > allow applications (sanitizers)
>> > to request *fixed* address ranges from the kernel at startup (so that
>> > the
>> > kernel couldn't refuse)?
>>
>> Wouldn't building non-PIE accomplish this?
>
>
> Well, many asan users do need PIE.
> Then, non-PIE only applies to the main executable, all DSOs are still
> PIC and the old change that moved DSOs from 0x7fff to 0x5555 caused us quite
> a bit of trouble too, even w/o PIE
Hm? You can build non-PIE executables leaving all the DSOs PIC.
Yes, but this won't help if the users actually want PIE executables.
If what you want is to entirely disable userspace ASLR under *San, you
can just set the ADDR_NO_RANDOMIZE personality flag.
Mmm. How? Could you please elaborate?
Do you suggest to call personality(ADDR_NO_RANDOMIZE) and re-execute the process? Or can I somehow set ADDR_NO_RANDOMIZE at link time?
-Kees
--
Kees Cook
Pixel Security
