linux-kernel - Re: [git pull] IOMMU Updates for Linux v5.15

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjTpYOsRPm4T2EV=Sxm52buZrMpRdwSDeedCSF4jh=M1w@mail.gmail.com>
Date:   Fri, 3 Sep 2021 11:43:31 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Joerg Roedel <joro@...tes.org>
Cc:     Will Deacon <will@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        iommu <iommu@...ts.linux-foundation.org>
Subject: Re: [git pull] IOMMU Updates for Linux v5.15

On Fri, Sep 3, 2021 at 7:03 AM Joerg Roedel <joro@...tes.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.15

So I've merged this, but I'm not entirely happy with some of the
rather insane Kconfig choices.

In particular, the defaults for this:

  choice
        prompt "IOMMU default domain type"
        depends on IOMMU_API
        default IOMMU_DEFAULT_DMA_LAZY if AMD_IOMMU || INTEL_IOMMU
        default IOMMU_DEFAULT_DMA_STRICT

seems fundamentally confused about what the h*ll is going on.

Why? Because a choice like "AMD_IOMMU" or "INTEL_IOMMU" isn't some
exclusive thing. You can have one or the other - or both. Or you could
have another IOMMU entirely, despite _also_ having AMD/INTEL_IOMMU
enabled as a config option.

IOW, maybe INTEL or AMD_IOMMU is enabled in the kernel configuration,
but that might not be the IOMMU that is then actually *active*.

The active IOMMU might be VIRTIO_IOMMU, for example.

See what I'm saying? Making the default be based on some random "this
driver is enabled" when it can then affect *other* drivers that are
also enabled and not part of the decision seems to be a fundamental
confusion about what is going on, when it's not at all clear which
driver will actually be IN USE.

Now, I don't think this _matters_ that much in practice, and as
mentioned, I already merged things.

But I think people should seriously think about either

 (a) make that default something that is actually *reliable*, so that
the fact that you have possibly enabled iommu X doesn't affect iommu Y
that is actually the one in use

or

 (b) make the defaults be actually per-driver, and set when the driver
is in *use* rather than this incorrect model of "enabled but maybe not
even used".

IOW, the fix might be to just say "the default is always lazy".

Or the fix might be something that is global to a configuration and
doesn't rely on which iommu is in use (eg "on x86, the default is
always LAZY")

Or the fix is to make that 'iommu_dma_strict' variable - and the
default value for it - be a per-IOMMU thing rather than be a global.

Hmm?

              Linus