[PATCH v3 4/4] ARM: Implement PAN for LPAE by TTBR0 page table walks disablement

[Florian Fainelli]

On 5/14/24 10:03, Russell King (Oracle) wrote:
> On Tue, May 14, 2024 at 09:54:07AM -0700, Florian Fainelli wrote:
>> On 5/14/24 09:06, Geert Uytterhoeven wrote:
>>> On Tue, May 14, 2024 at 1:28 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>> On Tue, May 14, 2024 at 10:25 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>>>>> On Tue, 14 May 2024 at 10:04, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>>>> On Tue, May 14, 2024 at 9:59 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>>>>>>> On Tue, 14 May 2024 at 09:46, Linus Walleij <linus.walleij at linaro.org> wrote:
>>>>>>>> On Tue, May 14, 2024 at 8:41 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>>>>>>
>>>>>>>>> I sent you a small initramfs by PM.
>>>>>>>>
>>>>>>>> Booted this just fine on Vexpress QEMU:
>>>>>>>>
>>>>>>>> Run /init as init process
>>>>>>>> sysctl: error: 'kernel.hotplug' is an unknown key
>>>>>>>>
>>>>>>>>
>>>>>>>> boot (Linux 6.9.0-rc1+, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
>>>>>>>> / # mount -t debugfs none /sys/kernel/debug
>>>>>>>> / # echo "ACCESS_USERSPACE" | cat >/sys/kernel/debug/provoke-crash/DIRECT
>>>>>>>> lkdtm: Performing direct entry ACCESS_USERSPACE
>>>>>>>> lkdtm: attempting bad read at 76fea000
>>>>>>>> 8<--- cut here ---
>>>>>>>> Unable to handle kernel paging request at virtual address 76fea000 when read
>>>>>>>> [76fea000] *pgd=82c93003, *pmd=82c94003, *pte=a00000811e2f5f
>>>>>>>> Internal error: Oops: 206 [#1] SMP ARM
>>>>>>>> CPU: 1 PID: 86 Comm: cat Not tainted 6.9.0-rc1+ #46
>>>>>>>> Hardware name: ARM-Versatile Express
>>>>>>>> PC is at lkdtm_ACCESS_USERSPACE+0xc0/0x138
>>>>>>>> LR is at lkdtm_ACCESS_USERSPACE+0xc0/0x138
>>>>>>>>
>>>>>>>> I'm starting to think it is something about different LPAE implementations here.
>>>>>>>
>>>>>>> I have built multi_v7_defconfig with the following enabled
>>>>>>>
>>>>>>> CONFIG_ARM_LPAE=y
>>>>>>> CONFIG_CPU_TTBR0_PAN=y
>>>>>>> CONFIG_LKDTM=y
>>>>>>>
>>>>>>> and the resulting kernel boots happily as a 32-bit VM running under a
>>>>>>> Rpi4 KVM host.
>>>>>>>
>>>>>>> Could someone post an actual .config that reproduces this? Rpi4 is
>>>>>>> A72, which both works and doesn't work in Florian's testing, so I'd be
>>>>>>> highly surprised if this is not a config issue.
>>>>>>
>>>>>> shmobile_defconfig with CONFIG_LPAE=y added failed for me before.
>>>>>>
>>>>>> Building multi_v7_defconfig with the above enabled...
>>>>
>>>> And that works, while shmobile_defconfig with the above does not!
>>>> So it is config-related.
>>>
>>> I ran tools/testing/ktest/config-bisect.pl and found the "offending"
>>> config option: CONFIG_CC_OPTIMIZE_FOR_SIZE=y gives a broken
>>> kernel, CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y works.
>>> (verified by just enabling CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE in my
>>>    broken config)....
>>
>> I second that, my working configuration has
>> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y whereas my
>> broken one has CONFIG_CC_OPTIMIZE_FOR_SIZE=y, sure enough, changing the
>> broken configuration to have CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y turns it
>> into a "working" configuration on the Raspberry Pi 4B in AArch32 mode.
>>
>> That makes more sense because BCM7211 and BCM2711 are exactly the same CPU,
>> thanks for restoring sanity!
> 
> I would imagine that the problem is cpu_set_ttbcr(). Please try adding
> a "memory" clobber to the asm() instruction in there.
> 

I can confirm that with CONFIG_CC_OPTIMIZE_FOR_SIZE=y and the hunk below:

diff --git a/arch/arm/include/asm/proc-fns.h 
b/arch/arm/include/asm/proc-fns.h
index 9b3105a2a5e0..1087bd2af433 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -187,7 +187,7 @@ static inline unsigned int cpu_get_ttbcr(void)

  static inline void cpu_set_ttbcr(unsigned int ttbcr)
  {
-       asm("mcr p15, 0, %0, c2, c0, 2" : : "r" (ttbcr));
+       asm("mcr p15, 0, %0, c2, c0, 2" : : "r" (ttbcr) : "memory");
  }

  #else  /*!CONFIG_MMU */

my Raspberry Pi 4B in AArch32 mode boots and runs user-space properly.

Thanks a lot Russell!
-- 
Florian