On Mon, Aug 7, 2017 at 12:21 PM, Kees Cook <keescook@xxxxxxxxxx> wrote:
On Mon, Aug 7, 2017 at 12:16 PM, Kostya Serebryany <kcc@xxxxxxxxxx> wrote:
>
>
> 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.
But who wants a PIE executable that isn't randomized? (Or did I
misunderstand you? You want to allow userspace to declare the
randomization range?
Kind of.
Doesn't *San use fixed addresses already, so ASLR
isn't actually a security defense?
first of all, *San are not security mitigation tools, and if they weaken ASLR -- that's fine.
(asan *may* be considered as a mitigation tool even though it weakens ASLR because it provides stronger memory safety guarantees,
but it's still a weak mitigation, and an expensive one)
And if we did have such an
interface it would just lead us right back to security vulnerabilities
like the one this fix was trying to deal with ...)
>> 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?
I've normally seen it done with a launcher that sets the personality
and execs the desired executable.
Oh, a launcher (e.g. just using setarch) would be a huge pain to deploy.
Another future path would be to collapse the PIE load range into the
DSO load range (as now done when a loader executes a PIE binary).
-Kees
--
Kees Cook
Pixel Security
