Hi Nick, Kees, Ard, Thanks for the responses.
On Fri, Jun 21, 2019 at 01:27:45PM -0700, Nick Desaulniers wrote: > On Thu, Jun 20, 2019 at 1:17 AM Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: > > On Thu, 20 Jun 2019 at 09:47, Will Deacon <will.dea...@arm.com> wrote: > > > On the flip side, I worry that it could make debugging more difficult, > > > but I > > > don't know whether that's a genuine concern or not. I'm assuming you've > > > debugged your fair share of crashes from KASLR-enabled kernels; how bad is > > > it? (I'm thinking of the case where somebody mails you part of a panic log > > > and a .config). > > I don't recall specific cases where KASLR made debugging difficult. I > went and spoke to our stability team that debugs crash reports from > the field. My understanding is that we capture full ramdumps. They > have a lot of custom tooling for debugging, but they did not recall > ever having to disable KASLR to debug further. We've had KASLR > enabled since I think the 2016 Pixel 1, so I assume their tooling > accounts for the seed/offset. > > I think if a full ramdump of the kernel image is loaded into GDB with > the matching kernel image it "just works" but could be mistaken. For > external developers, "nokaslr" boot time param is pretty standard. > > > In fact, given how many Android phones are running this code: Nick, > > can you check if there are any KASLR related kernel fixes that haven't > > been upstreamed? > > I spoke with the android common kernel team that's trying to burn down > their out of tree patches. I triple checked a doc they had where they > had audited every last patch, looking for for KASLR and > CONFIG_RANDOMIZE_BASE. I also triple checked our internal bug tracker > for burning down the out of tree patches. Finally I'm scanning each > branch of our android-common trees via `git log --all --grep > <KASLR|CONFIG_RANDOMIZE_BASE>`. I haven't found anything yet, and the > team doesn't expect any out of tree patches related to that feature. > Sorry for not responding sooner, but I'm still going through our 4.4, > 4.9, 4.14, and 4.19 branches. Thanks for having a look. It could be that we've fixed the issue Catalin was running into in the past -- he was going to see if the problem persists with mainline, since it was frequent enough that it was causing us to ignore the results from our testing infrastructure when RANDOMIZE_BASE=y. > > 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 mean, we could have RANDOMIZE_BASE select UNMAP_KERNEL_AT_EL0 if you like? The latter is already default y and hidden behind EXPERT. > > 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.biesheu...@linaro.org> > > Olof mentioned on IRC that I should resend without the other defconfig > changes. Do others have thoughts on that? That's not a bad idea. If you do that, feel free to add my Ack to the one adding RANDOMIZE_BASE=y: Acked-by: Will Deacon <w...@kernel.org> Will