| Message ID | 20190115184917.248995-1-james.morse@arm.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Commit | 2f97967503df8e45bc256a348b6f050abd2a38ed |
| Headers | show |
| Series | arm64: kpti: Update arm64_kernel_use_ng_mappings() when forced on | expand |
On 15/01/2019 18:49, James Morse wrote: > Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't want to cry wolf) report yesterday that the symptom I saw (boot delay) has been seen on 5.0-rc2 on our D06 board. I could not see it. Please note that this would be same board which we saw this on: https://lkml.org/lkml/2018/6/20/589 I only witnessed the issue on the predecessor A72-based D05 board. The reporter is very busy, but we'll keep tabs on it. Thanks, John > tables when KASLR is enabled"), a kernel built with CONFIG_RANDOMIZE_BASE > can decide early whether to use non-global mappings by checking the > kaslr_offset(). > > A kernel built without CONFIG_RANDOMIZE_BASE, instead checks the > cpufeature static-key. > > This leaves a gap where CONFIG_RANDOMIZE_BASE was enabled, no > kaslr seed was provided, but kpti was forced on using the cmdline > option. > > When the decision is made late, kpti_install_ng_mappings() will re-write > the page tables, but arm64_kernel_use_ng_mappings()'s value does not > change as it only tests the cpufeature static-key if > CONFIG_RANDOMIZE_BASE is disabled. > This function influences PROT_DEFAULT via PTE_MAYBE_NG, and causes > pgattr_change_is_safe() to catch nG->G transitions when the unchanged > PROT_DEFAULT is used as part of PAGE_KERNEL_RO: > [ 1.942255] alternatives: patching kernel code > [ 1.998288] ------------[ cut here ]------------ > [ 2.000693] kernel BUG at arch/arm64/mm/mmu.c:165! > [ 2.019215] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > [ 2.020257] Modules linked in: > [ 2.020807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2 #51 > [ 2.021917] Hardware name: linux,dummy-virt (DT) > [ 2.022790] pstate: 40000005 (nZcv daif -PAN -UAO) > [ 2.023742] pc : __create_pgd_mapping+0x508/0x6d0 > [ 2.024671] lr : __create_pgd_mapping+0x500/0x6d0 > > [ 2.058059] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____)) > [ 2.059369] Call trace: > [ 2.059845] __create_pgd_mapping+0x508/0x6d0 > [ 2.060684] update_mapping_prot+0x48/0xd0 > [ 2.061477] mark_linear_text_alias_ro+0xdc/0xe4 > [ 2.070502] smp_cpus_done+0x90/0x98 > [ 2.071216] smp_init+0x100/0x114 > [ 2.071878] kernel_init_freeable+0xd4/0x220 > [ 2.072750] kernel_init+0x10/0x100 > [ 2.073455] ret_from_fork+0x10/0x18 > > [ 2.075414] ---[ end trace 3572f3a7782292de ]--- > [ 2.076389] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > > If arm64_kernel_unmapped_at_el0() is true, arm64_kernel_use_ng_mappings() > should also be true. > > Signed-off-by: James Morse <james.morse@arm.com> > CC: Ard Biesheuvel <ard.biesheuvel@linaro.org> > CC: John Garry <john.garry@huawei.com> > CC: Will Deacon <will.deacon@arm.com> > > --- > arch/arm64/include/asm/mmu.h | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h > index ac352accb3d9..3e8063f4f9d3 100644 > --- a/arch/arm64/include/asm/mmu.h > +++ b/arch/arm64/include/asm/mmu.h > @@ -60,8 +60,11 @@ static inline bool arm64_kernel_use_ng_mappings(void) > * later determine that kpti is required, then > * kpti_install_ng_mappings() will make them non-global. > */ > + if (arm64_kernel_unmapped_at_el0()) > + return true; > + > if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE)) > - return arm64_kernel_unmapped_at_el0(); > + return false; > > /* > * KASLR is enabled so we're going to be enabling kpti on non-broken >
Hi John, On 16/01/2019 09:38, John Garry wrote: > On 15/01/2019 18:49, James Morse wrote: >> Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > > About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't want to > cry wolf) report yesterday that the symptom I saw (boot delay) has been seen on > 5.0-rc2 on our D06 board. I could not see it. You can still cause kpti_install_ng_mappings() to rewrite the page-tables if you don't have CONFIG_RANDOMIZE_BASE (or there is no seed), so its not enabled early, and unmap_kernel_at_el0() thinks the CPU is vulnerable, so enables it late. > Please note that this would be same board which we saw this on: > https://lkml.org/lkml/2018/6/20/589 > > I only witnessed the issue on the predecessor A72-based D05 board. 2a355ec25729 whitelisted the CPUs on this board. Unless you force kpti on, and disable KASLR you shouldn't see it. > The reporter is very busy, but we'll keep tabs on it. Thanks! James
On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: > On 16/01/2019 09:38, John Garry wrote: > > On 15/01/2019 18:49, James Morse wrote: > > > Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > > > > About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't > > want to cry wolf) report yesterday that the symptom I saw (boot delay) > > has been seen on 5.0-rc2 on our D06 board. I could not see it. > > > > Please note that this would be same board which we saw this on: > > https://lkml.org/lkml/2018/6/20/589 > > > > I only witnessed the issue on the predecessor A72-based D05 board. > > > > The reporter is very busy, but we'll keep tabs on it. > > > > FYI, this just came in this morning: This isn't completely surprising, because the kernel doesn't know about the CPU in D06: > [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] [...] > [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) If the CPU is not affected by meltdown, you can add the MIDR above to the kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid that you're stuck with the delay at boot for !KASLR kernels (which is an awful lot better than getting pwned by userspace :) I think D06 is 8.2, so I would've hoped that you'd implemented AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting unnecessary. Will
On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: > > On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: > > On 16/01/2019 09:38, John Garry wrote: > > > On 15/01/2019 18:49, James Morse wrote: > > > > Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > > > > > > About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't > > > want to cry wolf) report yesterday that the symptom I saw (boot delay) > > > has been seen on 5.0-rc2 on our D06 board. I could not see it. > > > > > > Please note that this would be same board which we saw this on: > > > https://lkml.org/lkml/2018/6/20/589 > > > > > > I only witnessed the issue on the predecessor A72-based D05 board. > > > > > > The reporter is very busy, but we'll keep tabs on it. > > > > > > > FYI, this just came in this morning: > > This isn't completely surprising, because the kernel doesn't know about > the CPU in D06: > > > [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] > > [...] > > > [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) > > If the CPU is not affected by meltdown, you can add the MIDR above to the > kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid > that you're stuck with the delay at boot for !KASLR kernels (which is an > awful lot better than getting pwned by userspace :) > > I think D06 is 8.2, so I would've hoped that you'd implemented > AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting > unnecessary. > Note that this is also still tied to the new rodata handling. The new default is rodata=full, and reverting back to rodata=on (which used to be the default in prior releases) or rodata=off (not recommended) should get around this as well.
On Fri, Mar 01, 2019 at 12:43:01PM +0100, Ard Biesheuvel wrote: > On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: > > > > On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: > > > On 16/01/2019 09:38, John Garry wrote: > > > > On 15/01/2019 18:49, James Morse wrote: > > > > > Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > > > > > > > > About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't > > > > want to cry wolf) report yesterday that the symptom I saw (boot delay) > > > > has been seen on 5.0-rc2 on our D06 board. I could not see it. > > > > > > > > Please note that this would be same board which we saw this on: > > > > https://lkml.org/lkml/2018/6/20/589 > > > > > > > > I only witnessed the issue on the predecessor A72-based D05 board. > > > > > > > > The reporter is very busy, but we'll keep tabs on it. > > > > > > > > > > FYI, this just came in this morning: > > > > This isn't completely surprising, because the kernel doesn't know about > > the CPU in D06: > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] > > > > [...] > > > > > [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) > > > > If the CPU is not affected by meltdown, you can add the MIDR above to the > > kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid > > that you're stuck with the delay at boot for !KASLR kernels (which is an > > awful lot better than getting pwned by userspace :) > > > > I think D06 is 8.2, so I would've hoped that you'd implemented > > AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting > > unnecessary. > > > > Note that this is also still tied to the new rodata handling. The new > default is rodata=full, and reverting back to rodata=on (which used to > be the default in prior releases) or rodata=off (not recommended) > should get around this as well. Or, somewhat perversely, enabling CONFIG_RANDOMIZE_BASE and passing a valid kaslr seed. Performance /and/ security! Will
On Fri, 1 Mar 2019 at 12:45, Will Deacon <will.deacon@arm.com> wrote: > > On Fri, Mar 01, 2019 at 12:43:01PM +0100, Ard Biesheuvel wrote: > > On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: > > > > > > On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: > > > > On 16/01/2019 09:38, John Garry wrote: > > > > > On 15/01/2019 18:49, James Morse wrote: > > > > > > Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > > > > > > > > > > About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't > > > > > want to cry wolf) report yesterday that the symptom I saw (boot delay) > > > > > has been seen on 5.0-rc2 on our D06 board. I could not see it. > > > > > > > > > > Please note that this would be same board which we saw this on: > > > > > https://lkml.org/lkml/2018/6/20/589 > > > > > > > > > > I only witnessed the issue on the predecessor A72-based D05 board. > > > > > > > > > > The reporter is very busy, but we'll keep tabs on it. > > > > > > > > > > > > > FYI, this just came in this morning: > > > > > > This isn't completely surprising, because the kernel doesn't know about > > > the CPU in D06: > > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] > > > > > > [...] > > > > > > > [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) > > > > > > If the CPU is not affected by meltdown, you can add the MIDR above to the > > > kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid > > > that you're stuck with the delay at boot for !KASLR kernels (which is an > > > awful lot better than getting pwned by userspace :) > > > > > > I think D06 is 8.2, so I would've hoped that you'd implemented > > > AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting > > > unnecessary. > > > > > > > Note that this is also still tied to the new rodata handling. The new > > default is rodata=full, and reverting back to rodata=on (which used to > > be the default in prior releases) or rodata=off (not recommended) > > should get around this as well. > > Or, somewhat perversely, enabling CONFIG_RANDOMIZE_BASE and passing a > valid kaslr seed. Performance /and/ security! > Yeah but unfortunately, it seems the UEFI on that box does not implement EFI_RNG_PROTOCOL.
On 2019/3/1 19:46, Ard Biesheuvel wrote: > On Fri, 1 Mar 2019 at 12:45, Will Deacon <will.deacon@arm.com> wrote: >> >> On Fri, Mar 01, 2019 at 12:43:01PM +0100, Ard Biesheuvel wrote: >>> On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: >>>> >>>> On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: >>>>> On 16/01/2019 09:38, John Garry wrote: >>>>>> On 15/01/2019 18:49, James Morse wrote: >>>>>>> Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page >>>>>> >>>>>> About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't >>>>>> want to cry wolf) report yesterday that the symptom I saw (boot delay) >>>>>> has been seen on 5.0-rc2 on our D06 board. I could not see it. >>>>>> >>>>>> Please note that this would be same board which we saw this on: >>>>>> https://lkml.org/lkml/2018/6/20/589 >>>>>> >>>>>> I only witnessed the issue on the predecessor A72-based D05 board. >>>>>> >>>>>> The reporter is very busy, but we'll keep tabs on it. >>>>>> >>>>> >>>>> FYI, this just came in this morning: >>>> >>>> This isn't completely surprising, because the kernel doesn't know about >>>> the CPU in D06: >>>> >>>>> [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] >>>> >>>> [...] >>>> >>>>> [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) >>>> >>>> If the CPU is not affected by meltdown, you can add the MIDR above to the >>>> kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid >>>> that you're stuck with the delay at boot for !KASLR kernels (which is an >>>> awful lot better than getting pwned by userspace :) >>>> >>>> I think D06 is 8.2, so I would've hoped that you'd implemented >>>> AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting >>>> unnecessary. D06 has the function of AA64PFR0_EL1.CSV3 but didn't set the bit, and it's not affected by meltdown... >>>> >>> >>> Note that this is also still tied to the new rodata handling. The new >>> default is rodata=full, and reverting back to rodata=on (which used to >>> be the default in prior releases) or rodata=off (not recommended) >>> should get around this as well. >> >> Or, somewhat perversely, enabling CONFIG_RANDOMIZE_BASE and passing a >> valid kaslr seed. Performance /and/ security! >> > > Yeah but unfortunately, it seems the UEFI on that box does not > implement EFI_RNG_PROTOCOL. Eagle eye :) So if we implement EFI_RNG_PROTOCOL (will take some time) in firmware and enable CONFIG_RANDOMIZE_BASE, the issue will gone, right? Thanks Hanjun
On Fri, Mar 01, 2019 at 08:59:19PM +0800, Hanjun Guo wrote: > On 2019/3/1 19:46, Ard Biesheuvel wrote: > > On Fri, 1 Mar 2019 at 12:45, Will Deacon <will.deacon@arm.com> wrote: > >> > >> On Fri, Mar 01, 2019 at 12:43:01PM +0100, Ard Biesheuvel wrote: > >>> On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: > >>>> > >>>> On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: > >>>>> On 16/01/2019 09:38, John Garry wrote: > >>>>>> On 15/01/2019 18:49, James Morse wrote: > >>>>>>> Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page > >>>>>> > >>>>>> About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't > >>>>>> want to cry wolf) report yesterday that the symptom I saw (boot delay) > >>>>>> has been seen on 5.0-rc2 on our D06 board. I could not see it. > >>>>>> > >>>>>> Please note that this would be same board which we saw this on: > >>>>>> https://lkml.org/lkml/2018/6/20/589 > >>>>>> > >>>>>> I only witnessed the issue on the predecessor A72-based D05 board. > >>>>>> > >>>>>> The reporter is very busy, but we'll keep tabs on it. > >>>>>> > >>>>> > >>>>> FYI, this just came in this morning: > >>>> > >>>> This isn't completely surprising, because the kernel doesn't know about > >>>> the CPU in D06: > >>>> > >>>>> [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] > >>>> > >>>> [...] > >>>> > >>>>> [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) > >>>> > >>>> If the CPU is not affected by meltdown, you can add the MIDR above to the > >>>> kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid > >>>> that you're stuck with the delay at boot for !KASLR kernels (which is an > >>>> awful lot better than getting pwned by userspace :) > >>>> > >>>> I think D06 is 8.2, so I would've hoped that you'd implemented > >>>> AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting > >>>> unnecessary. > > D06 has the function of AA64PFR0_EL1.CSV3 but didn't set the bit, and > it's not affected by meltdown... > > >>>> > >>> > >>> Note that this is also still tied to the new rodata handling. The new > >>> default is rodata=full, and reverting back to rodata=on (which used to > >>> be the default in prior releases) or rodata=off (not recommended) > >>> should get around this as well. > >> > >> Or, somewhat perversely, enabling CONFIG_RANDOMIZE_BASE and passing a > >> valid kaslr seed. Performance /and/ security! > >> > > > > Yeah but unfortunately, it seems the UEFI on that box does not > > implement EFI_RNG_PROTOCOL. > > Eagle eye :) So if we implement EFI_RNG_PROTOCOL (will take some time) in > firmware and enable CONFIG_RANDOMIZE_BASE, the issue will gone, right? Yup, but you can also update the MIDR whitelist since you're not affected by meltdown. Will
On 2019/3/1 21:02, Will Deacon wrote: > On Fri, Mar 01, 2019 at 08:59:19PM +0800, Hanjun Guo wrote: >> On 2019/3/1 19:46, Ard Biesheuvel wrote: >>> On Fri, 1 Mar 2019 at 12:45, Will Deacon <will.deacon@arm.com> wrote: >>>> >>>> On Fri, Mar 01, 2019 at 12:43:01PM +0100, Ard Biesheuvel wrote: >>>>> On Fri, 1 Mar 2019 at 12:35, Will Deacon <will.deacon@arm.com> wrote: >>>>>> >>>>>> On Fri, Mar 01, 2019 at 11:18:21AM +0000, John Garry wrote: >>>>>>> On 16/01/2019 09:38, John Garry wrote: >>>>>>>> On 15/01/2019 18:49, James Morse wrote: >>>>>>>>> Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page >>>>>>>> >>>>>>>> About b89d82ef01b3, I got an *unconfirmed* (emphasis on this, I don't >>>>>>>> want to cry wolf) report yesterday that the symptom I saw (boot delay) >>>>>>>> has been seen on 5.0-rc2 on our D06 board. I could not see it. >>>>>>>> >>>>>>>> Please note that this would be same board which we saw this on: >>>>>>>> https://lkml.org/lkml/2018/6/20/589 >>>>>>>> >>>>>>>> I only witnessed the issue on the predecessor A72-based D05 board. >>>>>>>> >>>>>>>> The reporter is very busy, but we'll keep tabs on it. >>>>>>>> >>>>>>> >>>>>>> FYI, this just came in this morning: >>>>>> >>>>>> This isn't completely surprising, because the kernel doesn't know about >>>>>> the CPU in D06: >>>>>> >>>>>>> [ 0.000000] Booting Linux on physical CPU 0x0000010000 [0x480fd010] >>>>>> >>>>>> [...] >>>>>> >>>>>>> [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) >>>>>> >>>>>> If the CPU is not affected by meltdown, you can add the MIDR above to the >>>>>> kpti_safe_list[] table. If it *is* affected by meltdown, then I'm afraid >>>>>> that you're stuck with the delay at boot for !KASLR kernels (which is an >>>>>> awful lot better than getting pwned by userspace :) >>>>>> >>>>>> I think D06 is 8.2, so I would've hoped that you'd implemented >>>>>> AA64PFR0_EL1.CSV3, which would make this MIDR-based whitelisting >>>>>> unnecessary. >> >> D06 has the function of AA64PFR0_EL1.CSV3 but didn't set the bit, and >> it's not affected by meltdown... >> >>>>>> >>>>> >>>>> Note that this is also still tied to the new rodata handling. The new >>>>> default is rodata=full, and reverting back to rodata=on (which used to >>>>> be the default in prior releases) or rodata=off (not recommended) >>>>> should get around this as well. >>>> >>>> Or, somewhat perversely, enabling CONFIG_RANDOMIZE_BASE and passing a >>>> valid kaslr seed. Performance /and/ security! >>>> >>> >>> Yeah but unfortunately, it seems the UEFI on that box does not >>> implement EFI_RNG_PROTOCOL. >> >> Eagle eye :) So if we implement EFI_RNG_PROTOCOL (will take some time) in >> firmware and enable CONFIG_RANDOMIZE_BASE, the issue will gone, right? > > Yup, but you can also update the MIDR whitelist since you're not affected by > meltdown. Thanks for the guidance, Performance /and/ security is what I prefer :) I take a look at the code, the logic in unmap_kernel_at_el0() shows that even I add D06's CPU in kpti_safe_list[] table, I can still enable CONFIG_RANDOMIZE_BASE + UEFI EFI_RNG_PROTOCOL to get performance and security. So it would be useful to prepare a patch to add D06 CPU's MIDR to kpti_safe_list[] table, to prevent some mis-use case such as above. Thanks Hanjun
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h index ac352accb3d9..3e8063f4f9d3 100644 --- a/arch/arm64/include/asm/mmu.h +++ b/arch/arm64/include/asm/mmu.h @@ -60,8 +60,11 @@ static inline bool arm64_kernel_use_ng_mappings(void) * later determine that kpti is required, then * kpti_install_ng_mappings() will make them non-global. */ + if (arm64_kernel_unmapped_at_el0()) + return true; + if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE)) - return arm64_kernel_unmapped_at_el0(); + return false; /* * KASLR is enabled so we're going to be enabling kpti on non-broken
Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page tables when KASLR is enabled"), a kernel built with CONFIG_RANDOMIZE_BASE can decide early whether to use non-global mappings by checking the kaslr_offset(). A kernel built without CONFIG_RANDOMIZE_BASE, instead checks the cpufeature static-key. This leaves a gap where CONFIG_RANDOMIZE_BASE was enabled, no kaslr seed was provided, but kpti was forced on using the cmdline option. When the decision is made late, kpti_install_ng_mappings() will re-write the page tables, but arm64_kernel_use_ng_mappings()'s value does not change as it only tests the cpufeature static-key if CONFIG_RANDOMIZE_BASE is disabled. This function influences PROT_DEFAULT via PTE_MAYBE_NG, and causes pgattr_change_is_safe() to catch nG->G transitions when the unchanged PROT_DEFAULT is used as part of PAGE_KERNEL_RO: [ 1.942255] alternatives: patching kernel code [ 1.998288] ------------[ cut here ]------------ [ 2.000693] kernel BUG at arch/arm64/mm/mmu.c:165! [ 2.019215] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 2.020257] Modules linked in: [ 2.020807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2 #51 [ 2.021917] Hardware name: linux,dummy-virt (DT) [ 2.022790] pstate: 40000005 (nZcv daif -PAN -UAO) [ 2.023742] pc : __create_pgd_mapping+0x508/0x6d0 [ 2.024671] lr : __create_pgd_mapping+0x500/0x6d0 [ 2.058059] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____)) [ 2.059369] Call trace: [ 2.059845] __create_pgd_mapping+0x508/0x6d0 [ 2.060684] update_mapping_prot+0x48/0xd0 [ 2.061477] mark_linear_text_alias_ro+0xdc/0xe4 [ 2.070502] smp_cpus_done+0x90/0x98 [ 2.071216] smp_init+0x100/0x114 [ 2.071878] kernel_init_freeable+0xd4/0x220 [ 2.072750] kernel_init+0x10/0x100 [ 2.073455] ret_from_fork+0x10/0x18 [ 2.075414] ---[ end trace 3572f3a7782292de ]--- [ 2.076389] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b If arm64_kernel_unmapped_at_el0() is true, arm64_kernel_use_ng_mappings() should also be true. Signed-off-by: James Morse <james.morse@arm.com> CC: Ard Biesheuvel <ard.biesheuvel@linaro.org> CC: John Garry <john.garry@huawei.com> CC: Will Deacon <will.deacon@arm.com> --- arch/arm64/include/asm/mmu.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)