On Mon, Aug 7, 2017 at 12:12 PM, Kees Cook <keescook@google.com> wrote:
On Mon, Aug 7, 2017 at 12:05 PM, Kostya Serebryany <kcc@google.com> wrote:
>
>
> On Mon, Aug 7, 2017 at 11:59 AM, Kees Cook <keescook@google.com> wrote:
>>
>> On Mon, Aug 7, 2017 at 11:56 AM, Kostya Serebryany <kcc@google.com> 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