Messages in this thread | | | From | Ard Biesheuvel <> | Date | Tue, 25 Jun 2019 17:42:49 +0200 | Subject | Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE |
| |
On Tue, 25 Jun 2019 at 17:39, Catalin Marinas <catalin.marinas@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 <will@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)
| |