On Tue, 25 Jun 2019 at 17:39, Catalin Marinas <catalin.mari...@arm.com> wrote: > > On Mon, Jun 24, 2019 at 12:06:18PM +0200, Ard Biesheuvel wrote: > > On Mon, 24 Jun 2019 at 11:57, Will Deacon <w...@kernel.org> wrote: > > > 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. > > > > I had no idea this was the case. I can look into it if we are still > > seeing failures. > > I've seen the panic below with 5.2-rc1, defconfig + RANDOMIZE_BASE=y in > a guest on TX2. It takes a few tries to trigger just with kaslr, > enabling lots of other DEBUG_* options makes the failures more > deterministic. I can't really say it's kaslr's fault here, only that I > used to consistently get it in this configuration. For some reason, I > can no longer reproduce it on arm64 for-next/core (or maybe it just > takes more tries and my script doesn't catch this). > > The fault is in the ip_tables module, the __this_cpu_read in > xt_write_recseq_begin() inlined in ipt_do_table(). The disassembled > sequence in my build: > > 0000000000000188 <ipt_do_table>: > ... > 258: d538d080 mrs x0, tpidr_el1 > 25c: aa1303f9 mov x25, x19 > 260: b8606b34 ldr w20, [x25, x0] >
This was fixed recently by arm64/kernel: kaslr: reduce module randomization range to 2 GB (and arm64/module: deal with ambiguity in PRELxx relocation ranges to some extent)
