LKRG: ISSUE: IOMMU table can't be found (skipping)

[sandikata]

It loads now, but i see another issue.

[ 70.577995] LKRG: ISSUE: IOMMU table can't be found (skipping)

Originally posted by @sandikata in https://github.com/lkrg-org/lkrg/issues/225#issuecomment-1228039200

[sandikata]

#( 08/26/22@ 7:27 )( root@aleksandrov ):~
   zgrep IOMMU /proc/config.gz
CONFIG_IRQ_MSI_IOMMU=y
CONFIG_GART_IOMMU=y
CONFIG_VFIO_IOMMU_TYPE1=y
CONFIG_VFIO_NOIOMMU=y
CONFIG_IOMMU_IOVA=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
CONFIG_IOMMU_IO_PGTABLE=y
# end of Generic IOMMU Pagetable Support
# CONFIG_IOMMU_DEBUGFS is not set
# CONFIG_IOMMU_DEFAULT_DMA_STRICT is not set
CONFIG_IOMMU_DEFAULT_DMA_LAZY=y
# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set
CONFIG_IOMMU_DMA=y
CONFIG_IOMMU_SVA=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON=y
CONFIG_HYPERV_IOMMU=y
CONFIG_VIRTIO_IOMMU=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_DEBUG is not set
#( 08/26/22@ 7:27 )( root@aleksandrov ):~

[solardiz]

@sandikata I'm sorry we did not comment sooner.

This is not a big deal - and, we're already doing the right thing by not treating this condition as an error, but just an issue worth noting in the log. While it's nice to protect the IOMMU table (and we do when we can), I'm not aware of any exploit targeting it anyway.

As to why this is failing for you, we don't really know. We look up these two symbols: __iommu_table and __iommu_table_end. They're normally defined in arch/x86/kernel/vmlinux.lds.S and used in arch/x86/kernel/pci-dma.c.

You might want to check the output of:

fgrep __iommu_table /proc/kallsyms

[solardiz]

FWIW, we're also seeing this ISSUE in some of our own tests, e.g. with mkosi-mainline here: https://github.com/lkrg-org/lkrg/runs/8150878349?check_suite_focus=true

Welcome to Ubuntu Kinetic Kudu (development branch) (GNU/Linux 6.0.0-060000rc2daily20220824-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
 * Management:     https://landscape.canonical.com/
 * Support:        https://ubuntu.com/advantage
Last login: Fri Sep  2 07:01:37 UTC 2022 on tty1
[   73.427101] kvm: Nested Virtualization enabled
[   73.427443] SVM: kvm: Nested Paging enabled
[   73.428037] SVM: Virtual GIF supported
[   73.428235] SVM: PMU virtualization is disabled
root@localhost:~# /lkrg/.github/workflows/run-boot-tests.sh
+ '[' '!' -d /sys/module/lkrg ']'
+ modprobe lkrg
[   77.363510] lkrg: loading out-of-tree module taints kernel.
[   77.370299] lkrg: module verification failed: signature and/or required key missing - tainting kernel
[   77.627519] LKRG: ALIVE: Loading LKRG
[   77.672099] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   77.675177] OOM killer disabled.
[   79.925471] LKRG: ISSUE: [kretprobe] register_kretprobe() for <ovl_dentry_is_whiteout> failed! [err=-2]
[   79.925935] LKRG: ISSUE: Can't hook 'ovl_dentry_is_whiteout'. This is expected when OverlayFS is not used.
[   83.056472] LKRG: ISSUE: IOMMU table can't be found (skipping)

[solardiz]

Turns out an upstream change broke our IOMMU table integrity checking... by making that unneeded?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78013eaadf696d2105982abb4018fbae394ca08f https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19

commit 78013eaadf696d2105982abb4018fbae394ca08f
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Feb 14 14:11:44 2022 +0100

    x86: remove the IOMMU table infrastructure

    The IOMMU table tries to separate the different IOMMUs into different
    backends, but actually requires various cross calls.

    Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
    in pci-dma.c and then just call into the IOMMU drivers.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

(actually merged in April)

@Adam-pi3 Maybe we should simply skip the code or suppress the message on 5.19+?

[Adam-pi3]

@solardiz Yes, we can do it. In fact, the IOMMU related code is moved to the vendor specific drivers but I'm not sure we want to go and support this path. I will work on PR to suppress this message for 5.19+ (and maybe later for backported LTS)