iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter

Bug #1810328 reported by Guilherme G. Piccoli on 2019-01-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Guilherme G. Piccoli
Guilherme G. Piccoli

Bug Description


* If the parameter "intel_iommu=off" is passed for the kernel in a boot instance coming from a previously iommu-enabled kernel (like a kexec/kdump scenario), currently Xenial kernel (4.4 version) is missing a patch to effectively disable the iommu. As a result, the previous DMA mappings remain and the new kernel will try to use them, which is wrong since we don't have iommu initialized to translate the addresses.

* The upstream patch proposed to SRU here, 161b28aae165 ("iommu/vt-d: Make sure IOMMUs are off when intel_iommu=off") fixes the issue by effectively disabling the iommu in case it was requested.

* One important use case is in a scenario of iommu bug that is leading to a kernel crash; kdump naturally will have the iommu tables copied from previous kernel in kdump boot time, so if iommu
tables are bogus, we could inherit the bug in the kdump kernel preventing a successful dump.
Have the ability to disable iommu (given that the functionality is there) is essential.

[Test Case]

* Boot a kernel with "intel_iommu=on", and then kexec a new kernel with "intel_iommu=off"
parameter. A kdump test is also possible, by changing the kdump command-line to disable
iommu (after booting a kernel with iommu enabled) - then, induce a crash and the issue
will show.

* Attached to this Launchpad are 2 files with the kdump test case: "iommu-missing" shows
the issue in a Trusty HWE kernel - without the fix patch, we can see messages like

[36.489918] DMAR: DRHD: handling fault status reg 202
[36.734830] DMAR: DMAR:[DMA Read] Request device [03:00.0] fault addr 3179a000
[36.734830] DMAR:[fault reason 06] PTE Read access is not set

In our case, the rootfs couldn't be initialized since the SCSI adapter wasn't initialized due to the DMAR failures (hpsa driver). Also, Solarflare NIC (sfc driver) couldn't get initialized too.

The patch fixed those error messages and the rootfs was mounted (see file "iommu-patched").
Notice the succeeding case couldn't kdump for other reasons, not strictly related to the proposed patch here.

[Regression Potential]

* iommu operations are complex and subject to HW issues eventually. Having iommu enabled
and then boot a kernel with this component disabled is inherently a "danger" operation from
drivers (or any users of such mappings) point-of-view. That said, I don't see a potential regression for this patch, in a way currently an user can't disable iommu properly if it was
once enabled, and this simple patch fixes it

* Care should be taken of course to not confuse regressions with problems induced by disabling the
iommu after it was enabled before (which would show that the patch works fine indeed, by allowing iommu to get disabled) - some drivers/devices may require iommu to be enabled in order to work, in such case disabling it would prevent the device to work.

Changed in linux (Ubuntu Xenial):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Guilherme G. Piccoli (gpiccoli)
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in linux (Ubuntu Xenial):
status: In Progress → Fix Committed
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
Guilherme G. Piccoli (gpiccoli) wrote :

Verification was done in Xenial kernel 4.4.0-142, available in -proposed pocket.

Basically, a regular boot with "intel_iommu=on" was completed, and then we kexec'ed
the same kernel, but now with "intel_iommu=off". Everything works as expected; before this patch inclusion, we saw DMAR errors (as mentioned in the description here) and the storage controller (hpsa driver) didn't work.



tags: added: verification-done-xenial
removed: verification-needed-xenial
Launchpad Janitor (janitor) wrote :
Download full text (33.2 KiB)

This bug was fixed in the package linux - 4.4.0-142.168

linux (4.4.0-142.168) xenial; urgency=medium

  * linux: 4.4.0-142.168 -proposed tracker (LP: #1811846)

  * Packaging resync (LP: #1786013)
    - [Packaging] update helper scripts

  * iptables connlimit allows more connections than the limit when using
    multiple CPUs (LP: #1811094)
    - netfilter: xt_connlimit: don't store address in the conn nodes
    - SAUCE: netfilter: xt_connlimit: remove the 'addr' parameter in add_hlist()
    - netfilter: nf_conncount: expose connection list interface
    - netfilter: nf_conncount: Fix garbage collection with zones
    - netfilter: nf_conncount: fix garbage collection confirm race
    - netfilter: nf_conncount: don't skip eviction when age is negative

  * CVE-2017-5715
    - SAUCE: x86/speculation: Cleanup IBPB runtime control handling
    - SAUCE: x86/speculation: Cleanup IBRS runtime control handling
    - SAUCE: x86/speculation: Use x86_spec_ctrl_base in entry/exit code
    - SAUCE: x86/speculation: Move RSB_CTXSW hunk

  * Xenial update: 4.4.167 upstream stable release (LP: #1811077)
    - media: em28xx: Fix use-after-free when disconnecting
    - Revert "wlcore: Add missing PM call for
    - rapidio/rionet: do not free skb before reading its length
    - s390/qeth: fix length check in SNMP processing
    - usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2
    - kvm: mmu: Fix race in emulated page table writes
    - xtensa: enable coprocessors that are being flushed
    - xtensa: fix coprocessor context offset definitions
    - Btrfs: ensure path name is null terminated at btrfs_control_ioctl
    - ALSA: wss: Fix invalid snd_free_pages() at error path
    - ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write
    - ALSA: control: Fix race between adding and removing a user element
    - ALSA: sparc: Fix invalid snd_free_pages() at error path
    - ext2: fix potential use after free
    - dmaengine: at_hdmac: fix memory leak in at_dma_xlate()
    - dmaengine: at_hdmac: fix module unloading
    - btrfs: release metadata before running delayed refs
    - USB: usb-storage: Add new IDs to ums-realtek
    - usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series
    - misc: mic/scif: fix copy-paste error in scif_create_remote_lookup
    - Kbuild: suppress packed-not-aligned warning for default setting only
    - exec: avoid gcc-8 warning for get_task_comm
    - disable stringop truncation warnings for now
    - kobject: Replace strncpy with memcpy
    - unifdef: use memcpy instead of strncpy
    - kernfs: Replace strncpy with memcpy
    - ip_tunnel: Fix name string concatenate in __ip_tunnel_create()
    - drm: gma500: fix logic error
    - scsi: bfa: convert to strlcpy/strlcat
    - staging: rts5208: fix gcc-8 logic error warning
    - kdb: use memmove instead of overlapping memcpy
    - iser: set sector for ambiguous mr status errors
    - uprobes: Fix handle_swbp() vs. unregister() + register() race once more
    - MIPS: ralink: Fix mt7620 nd_sd pinmux
    - mips: fix mips_get_syscall_arg o32 check
    - drm/ast: Fix incorrect free on ioregs

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers