On Mon, Aug 7, 2017 at 12:21 PM, Kees Cook <keescook@google.com> wrote:

> On Mon, Aug 7, 2017 at 12:16 PM, Kostya Serebryany <kcc@google.com> wrote:
> >
> >
> > 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.
>
> 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
>