Messages in this thread | | | From | Kees Cook <> | Date | Fri, 21 Jun 2019 13:54:10 -0700 | Subject | Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE |
| |
On Fri, Jun 21, 2019 at 1:28 PM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Thu, Jun 20, 2019 at 1:17 AM Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > > I think it is mostly controversial among non-security folks, who think > > that every mitigation by itself should be bullet proof. Security folks > > tend to think more about how each layer reduces the attack surface, > > hopefully resulting in a secure system when all layers are enabled. > > + Kees, Sami, Jeff > It's a relatively low cost part of our defense in depth strategy. > Maybe (Kees, Sami, Jeff) have more thoughts?
Right -- the thought is that it provides more benefit than complication. It is hardly a perfect defense, but it does provide building blocks to more interesting situations. For example, once execute-only memory is more common, KASLR + XOM means there is a not insignificant defense against automated ROP. And KASLR is a general precursor to fine-grained KASLR (i.e. randomizing on function).
> > So KASLR is known to be broken unless you enable KPTI as well, so that > > is something we could take into account. I.e., mitigations that don't > > reduce the attack surface at all are just pointless complexity, which > > should obviously be avoided. > > (Note to Sami + Jeff if they had KPTI on their radar)
I prefer that KPTI always stay enabled. :)
> > Another thing to note is that the runtime cost of KASLR is ~zero, with > > the exception of the module PLTs. However, the latter could do with > > some additional coverage as well, so in summary, I think enabling this > > is a good thing. Otherwise, we could disable full module randomization > > so that the module PLT code doesn't get used in practice. > > > > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
-- Kees Cook
| |