powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV

In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV

When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due

to NULL pointer exception:

Kernel attempted to read user page (0) - exploit attempt? (uid: 0)

BUG: Kernel NULL pointer dereference on read at 0x00000000

Faulting instruction address: 0xc000000020847ad4

Oops: Kernel access of bad area, sig: 11 [#1]

LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries

Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop

CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12

Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries

NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c

REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)

MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008

CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1

...

NIP _find_next_zero_bit+0x24/0x110

LR bitmap_find_next_zero_area_off+0x5c/0xe0

Call Trace:

dev_printk_emit+0x38/0x48 (unreliable)

iommu_area_alloc+0xc4/0x180

iommu_range_alloc+0x1e8/0x580

iommu_alloc+0x60/0x130

iommu_alloc_coherent+0x158/0x2b0

dma_iommu_alloc_coherent+0x3c/0x50

dma_alloc_attrs+0x170/0x1f0

mlx5_cmd_init+0xc0/0x760 [mlx5_core]

mlx5_function_setup+0xf0/0x510 [mlx5_core]

mlx5_init_one+0x84/0x210 [mlx5_core]

probe_one+0x118/0x2c0 [mlx5_core]

local_pci_probe+0x68/0x110

pci_call_probe+0x68/0x200

pci_device_probe+0xbc/0x1a0

really_probe+0x104/0x540

__driver_probe_device+0xb4/0x230

driver_probe_device+0x54/0x130

__driver_attach+0x158/0x2b0

bus_for_each_dev+0xa8/0x130

driver_attach+0x34/0x50

bus_add_driver+0x16c/0x300

driver_register+0xa4/0x1b0

__pci_register_driver+0x68/0x80

mlx5_init+0xb8/0x100 [mlx5_core]

do_one_initcall+0x60/0x300

do_init_module+0x7c/0x2b0

At the time of LPAR dump, before kexec hands over control to kdump

kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.

For the SR-IOV case, default DMA window "ibm,dma-window" is removed from

the FDT and DDW added, for the device.

Now, kexec hands over control to the kdump kernel.

When the kdump kernel initializes, PCI busses are scanned and IOMMU

group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV

case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,

fixes the path where memory is pre-mapped (direct mapped) to the DDW.

When TCEs are direct mapped, there is no need to initialize IOMMU

tables.

iommu_table_setparms_lpar() only considers "ibm,dma-window" property

when initiallizing IOMMU table. In the scenario where TCEs are

dynamically allocated for SR-IOV, newly created IOMMU table is not

initialized. Later, when the device driver tries to enter TCEs for the

SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().

The fix is to initialize the IOMMU table with DDW property stored in the

FDT. There are 2 points to remember:

1. For the dedicated adapter, kdump kernel would encounter both

default and DDW in FDT. In this case, DDW property is used to

initialize the IOMMU table.

2. A DDW could be direct or dynamic mapped. kdump kernel would

initialize IOMMU table and mark the existing DDW as

"dynamic". This works fine since, at the time of table

initialization, iommu_table_clear() makes some space in the

DDW, for some predefined number of TCEs which are needed for

kdump to succeed.