linux-kernel - Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+CmpXteN1PJEHMV8rvfeBXK6Eb4z6BgZwa8Ojavi1y9pKN-jA@mail.gmail.com>
Date:   Tue, 13 Nov 2018 17:38:53 +0200
From:   Yehezkel Bernat <yehezkelshb@...il.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     iommu@...ts.linux-foundation.org, joro@...tes.org,
        David Woodhouse <dwmw2@...radead.org>,
        baolu.lu@...ux.intel.com, ashok.raj@...el.com,
        Bjorn Helgaas <bhelgaas@...gle.com>, rjw@...ysocki.net,
        jacob.jun.pan@...el.com, Andreas Noever <andreas.noever@...il.com>,
        michael.jamet@...el.com, lukas@...ner.de,
        Christian Kellner <ckellner@...hat.com>,
        Mario Limonciello <Mario.Limonciello@...l.com>,
        Anthony Wong <anthony.wong@...onical.com>,
        linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection
 support to userspace

On Tue, Nov 13, 2018 at 5:20 PM Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
>
> On Tue, Nov 13, 2018 at 04:42:58PM +0200, Yehezkel Bernat wrote:
> > On Tue, Nov 13, 2018 at 1:40 PM Mika Westerberg
> > <mika.westerberg@...ux.intel.com> wrote:
> > >
> > > On Tue, Nov 13, 2018 at 01:13:31PM +0200, Yehezkel Bernat wrote:
> > > > On Tue, Nov 13, 2018 at 12:56 PM Mika Westerberg
> > > > <mika.westerberg@...ux.intel.com> wrote:
> > > > >
> > > > > > Just one point:
> > > > > > Have you considered the option to add this property per (TBT?) device?
> > > > >
> > > > > No. ;-)
> > > > >
> > > > > You mean that one device uses security levels and another IOMMU? I don't
> > > > > think it is possible without having some sort of table in the IOMMU
> > > > > driver telling which devices it needs identity map and which not. Also
> > > > > not sure what would be the benefit?
> > > >
> > > > For performance, of course. If some devices are considered safe (maybe a list
> > > > communicated by platform firmware), the kernel may decide to configure them to
> > > > passthrough the IOMMU (I think I remember there is such an option, but maybe I'm
> > > > wrong.)
> > >
> > > At least I'm not aware of such an option. Windows for example enables
> > > IOMMU for everything and I think macOS does the same. In Linux (with
> > > these patches) we put all internal devices already passthrough mode so
> > > things like internal graphics should not be affected. eGPUs are
> > > different thing, though.
> >
> > So your point here is "currently we do the IOMMU decisions system-wide; we can
> > always add a per-device attribute if needed"?
>
> Well, let me elaborate a bit :) I think it is possible to put certain
> devices into IOMMU passthrough mode even if they are "external" but I'm
> not that familiar with the guts of Intel IOMMU (Baolu or Ashok are the
> experts). Assuming it is possible we could have a table or similar in
> the kernel that can be used to identify devices that are allowed to be
> in passthrough mode.
>
> I'm not sure if it can be per-device sysfs attribute because at the time
> the PCIe device is enumerated it is already put to its IOMMU group.

Good point. But I thought about per-TBT-device decision. If the platform is
configured for IOMMU+"user" security level, while approving the device the user
may want to set also in which IOMMU group to put all the PCIe devices connected
to it. The same goes if kernel is supposed to auto-approve such devices based on
an internal table. The point is that we can think on a configuration where the
devices aren't tunneled yet and the decision about IOMMU can still be changed.

As you mentioned this isn't the common configuration anyway, so it probably
doesn't worth all this hassle.