Re: [PATCH v2 5/6] arch/*: increase lowmem size to avoid highmem use

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 9 potential
issues to consider:
- [High] powerpc: 85xx LOWMEM_CAM_NUM and PAGE_OFFSET cap lowmem at 768
  MiB
- [High] ARM: omap2: dropping HIGHMEM select limits multi_v7 and
  omap2plus to 1 GiB
- [High] KVM: PPC: e500: get_host_mas0() hits kernel TLB with
  PAGE_OFFSET 0x70000000
- [High] powerpc/47x: 2 GiB LOWMEM_SIZE triggers BUG_ON in
  ppc47x_pin_tlb()
- [High] KVM: PPC: BookE: hardcoded 0xc0000000 host IVPR breaks new
  KERNEL_START
- [High] KVM: PPC: Book3S: LOAD_HOST_SEGMENTS leaves kernel SRs 7..11
  unrestored
- [Medium] powerpc/kasan: 32-bit HIGHMEM lowmem overlaps KASAN shadow
  and fixmap
- [Medium] ARM: config: aspeed_g5: dropping HIGHMEM truncates 2 GiB
  AST2600 RAM
- [Medium] ARM: pxa: hardcoded 0xc0000000 dereference in
  pxa3xx_cpu_pm_suspend()
--

commit bedc943a8dd41812a1db37560a98b5754effd200
Author: Arnd Bergmann <arnd@arndb.de>

arch/*: increase lowmem size to avoid highmem use

This commit changes the default 32-bit virtual memory split on ARM, x86,
PowerPC, and MicroBlaze to provide 1 GiB of lowmem without HIGHMEM and up
to 1.75 GiB or 2 GiB of lowmem with HIGHMEM, and drops CONFIG_HIGHMEM from
several platform configs and defconfigs.

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 93350d2e51b99..fee6b7435b7ca 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1027,7 +1027,8 @@ config BL_SWITCHER_DUMMY_IF
>  choice
>  	prompt "Memory split"
>  	depends on MMU
> -	default VMSPLIT_3G
> +	default VMSPLIT_2G if HIGHMEM || ARM_LPAE
> +	default VMSPLIT_3G_OPT

[Severity: Medium]
Does switching the non-HIGHMEM default to VMSPLIT_3G_OPT (PAGE_OFFSET =
0xb0000000) break suspend-to-RAM on PXA3xx?

In pxa_pm_enter() -> pxa3xx_cpu_pm_enter() -> pxa3xx_cpu_pm_suspend(), the
code saves the first word of SDRAM and writes the physical resume address
for the boot ROM using a hardcoded 0xc0000000 virtual address instead of
PAGE_OFFSET:

arch/arm/mach-pxa/pxa3xx.c:pxa3xx_cpu_pm_suspend() {
	volatile unsigned long *p = (volatile void *)0xc0000000;
	unsigned long saved_data = *p;
...
	*p = __pa_symbol(cpu_resume);
}

On PXA3xx boards with 64 MiB or 128 MiB of RAM (such as pxa3xx_defconfig),
0xc0000000 is now in the vmalloc area rather than the start of SDRAM, so
entering PM_SUSPEND_MEM faults or corrupts vmalloc memory.

[ ... ]

> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index 45b937419dbda..5c5d831df36ab 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -27,7 +27,6 @@ CONFIG_SMP=y
>  # CONFIG_ARM_CPU_TOPOLOGY is not set
>  CONFIG_VMSPLIT_2G=y
>  CONFIG_NR_CPUS=2
> -CONFIG_HIGHMEM=y

[Severity: Medium]
Does dropping CONFIG_HIGHMEM=y from aspeed_g5_defconfig truncate RAM on
2 GiB AST2600 boards?

Despite its name, aspeed_g5_defconfig also enables CONFIG_MACH_ASPEED_G6=y
and explicitly selects CONFIG_VMSPLIT_2G=y.  Commit 4cdabee7d6d2 ("ARM:
configs: aspeed_g5: Enable AST2600") enabled CONFIG_HIGHMEM=y here because
AST2600 boards (such as aspeed-ast2600-evb.dts) have 2 GiB of RAM, while
CONFIG_VMSPLIT_2G=y without HIGHMEM only maps at most 1.75 GiB of lowmem
after reserving space for vmalloc, ioremap, and fixmap.

[ ... ]

> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index f0f1d7a8640ca..d145e448a6b80 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -135,7 +135,6 @@ config ARCH_OMAP2PLUS_TYPICAL
>  	bool "Typical OMAP configuration"
>  	default y
>  	select AEABI
> -	select HIGHMEM if !CPU_CACHE_VIVT
>  	select I2C
>  	select I2C_OMAP
>  	select MENELAUS if ARCH_OMAP2

[Severity: High]
Does removing this select silently disable CONFIG_HIGHMEM in both
multi_v7_defconfig and omap2plus_defconfig?

Neither defconfig contains an explicit CONFIG_HIGHMEM=y line because both
enable ARCH_OMAP2PLUS_TYPICAL, which previously selected HIGHMEM.  With
this line removed, both defconfigs build with CONFIG_HIGHMEM=n and fall
back to CONFIG_VMSPLIT_3G_OPT=y, limiting all 1.5 GiB to 4 GiB ARMv7
boards booted with multi_v7_defconfig or omap2plus_defconfig to 1 GiB of
RAM.

[ ... ]

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2580e27e43287..dfc4f518c6fb4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig

[ ... ]

> @@ -1193,7 +1194,8 @@ config LOWMEM_SIZE_BOOL
>  
>  config LOWMEM_SIZE
>  	hex "Maximum low memory size (in bytes)" if LOWMEM_SIZE_BOOL
> -	default "0x30000000"
> +	default "0x80000000" if HIGHMEM
> +	default "0x40000000"

[Severity: High]
On PPC_85xx, doesn't CONFIG_LOWMEM_CAM_NUM still cap lowmem at 768 MiB?

Right below LOWMEM_SIZE, LOWMEM_CAM_NUM still defaults to 3 (or 9/12/15
with STRICT_KERNEL_RWX, where the first 256 MiB uses 7/10/13 smaller CAMs).
Furthermore, because the new PAGE_OFFSET defaults (0xb0000000 and
0x70000000) are only 256 MiB-aligned, calc_cam_sz() bounds each CAM to
1UL << __ffs(virt | phys), which is at most 256 MiB at every 256 MiB
boundary.  As a result, MMU_init() -> adjust_total_lowmem() ->
map_mem_in_cams() still caps __max_low_memory at 3 * 256 MiB = 768 MiB:
non-HIGHMEM 85xx builds (including ksi8560_defconfig and stx_gp3_defconfig)
discard RAM above 768 MiB via memblock_enforce_memory_limit(), while
HIGHMEM 85xx builds shrink TASK_SIZE to 1.75 GiB without gaining any
lowmem.

[Severity: High]
Can a 2 GiB LOWMEM_SIZE trigger a boot BUG_ON in ppc47x_pin_tlb() on
PPC_47x systems with more than 1.5 GiB of RAM?

Unlike 85xx, 44x/47x does not call adjust_total_lowmem(), so mmu_mapin_ram()
pins 256 MiB TLB entries in a loop up to lowmem_end_addr (now up to 2 GiB
when HIGHMEM=y, such as in currituck_defconfig).  However, PPC47x hardware
only has 6 bolted TLB slots in ppc47x_find_free_bolted() (5 if
CONFIG_PPC_EARLY_DEBUG_44x=y uses slot 5), covering at most 1.5 GiB (or
1.25 GiB) before ppc47x_pin_tlb() hits BUG_ON(bolted < 0).  In addition,
dropping CONFIG_HIGHMEM=y from arch/powerpc/configs/44x/akebono_defconfig
limits the IBM Akebono PPC476GTR board, which supports multi-gigabyte DDR3
configurations via SWIOTLB, to 1 GiB of RAM.

> @@ -1245,7 +1247,8 @@ config PAGE_OFFSET_BOOL
>  
>  config PAGE_OFFSET
>  	hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
> -	default "0xc0000000"
> +	default "0x70000000" if HIGHMEM
> +	default "0xb0000000"

[Severity: Medium]
When both CONFIG_HIGHMEM=y and CONFIG_KASAN=y are enabled on 32-bit
PowerPC, does lowmem overlap the KASAN shadow and fixmap regions?

With PAGE_OFFSET at 0x70000000 and LOWMEM_SIZE at 0x80000000, lowmem can
extend up to 0xf0000000.  However, KASAN_SHADOW_OFFSET is fixed at
0xe0000000 in arch/powerpc/Kconfig.debug, which places KASAN_SHADOW_START
at 0xec000000 (with CONFIG_EXECMEM=y) or 0xee000000 (with CONFIG_EXECMEM=n)
and places FIXADDR_TOP, PKMAP_BASE, and VMALLOC_END below
KASAN_SHADOW_START, colliding with lowmem on systems with ~1.9 GiB or more
of RAM and triggering a boot BUG_ON in map_kernel_page().

[Severity: High]
With PAGE_OFFSET=0x70000000, can get_host_mas0() in the e500 KVM host MMU
match and overwrite a host kernel TLB entry instead of forcing a miss?

arch/powerpc/kvm/e500_mmu_host.c:get_host_mas0() {
	local_irq_save(flags);
	mtspr(SPRN_MAS6, 0);
	mas4 = mfspr(SPRN_MAS4);
	mtspr(SPRN_MAS4, mas4 & ~MAS4_TLBSEL_MASK);
	asm volatile("tlbsx 0, %0" : : "b" (eaddr & ~CONFIG_PAGE_OFFSET));
	mas0 = mfspr(SPRN_MAS0);
}

get_host_mas0() masks eaddr with ~CONFIG_PAGE_OFFSET to produce a userspace
address (< PAGE_OFFSET) that is guaranteed to miss in PID 0.  When
CONFIG_PAGE_OFFSET is 0x70000000, ~CONFIG_PAGE_OFFSET is 0x8fffffff, so any
guest eaddr >= 0x80000000 masks to 0x80000000..0x8fffffff, which lies
inside the host kernel linear mapping (>= 0x70000000) and can hit and
overwrite an active host kernel TLB entry in write_host_tlbe().

>  config KERNEL_START_BOOL
>  	bool "Set custom kernel base address"
> @@ -1261,8 +1264,9 @@ config KERNEL_START_BOOL
>  config KERNEL_START
>  	hex "Virtual address of kernel base" if KERNEL_START_BOOL
>  	default PAGE_OFFSET if PAGE_OFFSET_BOOL
> -	default "0xc2000000" if CRASH_DUMP && !NONSTATIC_KERNEL
> -	default "0xc0000000"
> +	default "0x72000000" if HIGHMEM && CRASH_DUMP && !NONSTATIC_KERNEL
> +	default "0xb2000000" if CRASH_DUMP && !NONSTATIC_KERNEL
> +	default PAGE_OFFSET

[Severity: High]
Does changing the default KERNEL_START away from 0xc0000000 break KVM guest
exit on 32-bit Book-E hosts?

On 85xx and 44x, interrupt_base is linked at KERNEL_START (now 0xb0000000
or 0x70000000 by default), but kvmppc_resume_host in
arch/powerpc/kvm/booke_interrupts.S restores the host SPRN_IVPR to a
hardcoded 0xc0000000:

	/* Restore host IVPR before re-enabling interrupts. We cheat and know
	 * that Linux IVPR is always 0xc0000000. */
	lis	r3, 0xc000
	mtspr	SPRN_IVPR, r3

The first host interrupt or exception after guest exit will jump to
0xc0000000 + IVOR offset instead of interrupt_base and crash the host.

> @@ -1298,7 +1302,7 @@ config TASK_SIZE_BOOL
>  config TASK_SIZE
>  	hex "Size of maximum user task space" if TASK_SIZE_BOOL
>  	default "0x80000000" if PPC_8xx
> -	default "0xc0000000"
> +	default PAGE_OFFSET

[Severity: High]
On 32-bit Book3S KVM hosts, does lowering TASK_SIZE and PAGE_OFFSET leave
host kernel segment registers 7..11 (or 11) unrestored on guest exit?

LOAD_GUEST_SEGMENTS in arch/powerpc/kvm/book3s_32_sr.S overwrites all 16
segment registers with guest values, but LOAD_HOST_SEGMENTS only restores
the 4 segment registers 0xc..0xf (0xc0000000..0xffffffff):

arch/powerpc/kvm/book3s_32_sr.S:LOAD_HOST_SEGMENTS {
        li      r0, 4
        mtctr   r0
	LOAD_REG_IMMEDIATE(r3, 0x20000000 | (0x111 * 0xc))
        lis     r4, 0xc000
3:      mtsrin  r3, r4
        addi    r3, r3, 0x111     /* increment VSID */
        addis   r4, r4, 0x1000    /* address of next segment */
        bdnz    3b
}

Because switch_mmu_context() -> update_user_segments() only reloads
0 .. NUM_USER_SEGMENTS - 1 (segments 0..10 when TASK_SIZE is 0xb0000000, or
0..6 when TASK_SIZE is 0x70000000), the host kernel segments covering
0xb0000000..0xbfffffff (or 0x70000000..0xbfffffff, plus any module/execmem
segment below PAGE_OFFSET) retain guest segment register values after
exiting the guest.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112112528.1116405-1-arnd@kernel.org?part=5