ctly marked and thus will end up fully protected.
>
> CC: Mario Limonciello
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Robin Murphy
Acked-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Mar 22, 2022 at 01:09:55PM -0700, Rajat Jain wrote:
> On Tue, Mar 22, 2022 at 4:12 AM Rafael J. Wysocki wrote:
> >
> > On Tue, Mar 22, 2022 at 10:02 AM Christoph Hellwig
> > wrote:
> > >
> > > On Sat, Mar 19, 2022 at 11:29:05PM -0700, Rajat Jain wrote:
> > > > Rename the field to make it
Hi Robin,
I tried this now on two Intel systems. One with integrated Thunderbolt
and one with discrete. There was a small issue, see below but once fixed
it worked as expected :)
On Fri, Mar 18, 2022 at 05:42:58PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Ma
r DMA attacks (e.g. internal network devices).
>
> Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin,
Thanks for working on this!
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
> that the iommu_dma_protection attribute is being fa
Hi Robin,
On Thu, Mar 17, 2022 at 01:42:56PM +, Robin Murphy wrote:
> On 2022-03-17 08:08, Mika Westerberg wrote:
> > Hi Robin,
> >
> > On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
> > > The feeling I'm getting from all
Hi Robin,
On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
> The feeling I'm getting from all this is that if we've got as far as
> iommu_dma_protection_show() then it's really too late to meaningfully
> mitigate bad firmware.
Note, these are requirements from Microsoft in order for
Hi Mario,
On Wed, Mar 16, 2022 at 06:34:51PM +, Limonciello, Mario wrote:
> > Might it be reasonable for the Thunderbolt core to check early on if any
> > tunnelled ports are not marked as external facing, and if so just tell
> > the user that iommu_dma_protection is off the table and anything
Hi Mario,
On Wed, Mar 16, 2022 at 05:24:38PM +, Limonciello, Mario wrote:
> [Public]
>
> > On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
> > > > What we want is to make sure the Tunneled PCIe ports get the full
> > IOMMU
> > > > protection. In case of the discrete above it is
Hi,
On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
> > What we want is to make sure the Tunneled PCIe ports get the full IOMMU
> > protection. In case of the discrete above it is also fine if all the
> > devices behind the PCIe root port get the full IOMMU protection. Note in
> > th
Hi Robin,
On Wed, Mar 16, 2022 at 11:25:51AM +, Robin Murphy wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device
> we care about. Furthermore, the presence or not of one firmware flag
> doesn't im
Hi,
On Tue, Mar 15, 2022 at 01:36:11PM -0500, Limonciello, Mario wrote:
> + Christian Kellner (Bolt userspace maintainer)
>
> On 3/15/2022 13:07, Robin Murphy wrote:
> > On 2022-03-15 16:54, Limonciello, Mario via iommu wrote:
> > > [Public]
> > >
> > >
> > > > On Tue, Mar 15, 2022 at 11:24:55A
On Mon, Jun 15, 2020 at 06:17:40PM -0700, Rajat Jain wrote:
> The "ExternalFacing" devices (root ports) are still internal devices
> that sit on the internal system fabric and thus trusted. Currently they
> were being marked untrusted - likely as an unintended border case.
It was actually intentio
iommu/vt-d: Force IOMMU on for platform opt in hint")
> Cc: Mika Westerberg
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
e device we are applying quirks to, is
> indeed an internal trusted device.
>
> Signed-off-by: Rajat Jain
> Acked-by: Lu Baolu
> Reviewed-by: Ashok Raj
Looks good now, thanks!
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@li
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> +static bool risky_device(struct pci_dev *pdev)
> +{
> + if (pdev->untrusted) {
> + pci_warn(pdev,
> + "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> + " PCI link. Plea
On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure that the device we are ap
On Tue, Sep 24, 2019 at 10:37:39PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@li
On Tue, Sep 24, 2019 at 10:37:37PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@li
On Tue, Sep 24, 2019 at 10:37:38PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@li
, hid2))
> + return false;
> +
> + if (!uid2)
> + return true;
> +
> + return uid1 && !strcmp(uid1, uid2);
> +}
> +EXPORT_SYMBOL(acpi_dev_hid_uid_match);
Should this be _GPL?
In any case looks good,
Reviewed-by: Mika Westerberg
>
> Thus, move acpi_dev_get_first_match_dev() under CONFIG_ACPI as well.
>
> Fixes: 817b4d64da03 ("Introduce acpi_dev_get_first_match_dev() helper")
> Reported-by: kbuild test robot
> Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
_
acpi/utils.c:513: warning: Function parameter or member 'handle' not
> described in '__acpi_handle_debug'
> drivers/acpi/utils.c:513: warning: Function parameter or member 'fmt' not
> described in '__acpi_handle_debug'
>
> Describe
On Wed, Jun 12, 2019 at 11:00:06AM +0800, Lu Baolu wrote:
> > What kind of devices did you test it with?
>
> Most test work was done by Xu Pengfei (cc'ed). He has run the code
> on real platforms with various thunderbolt peripherals (usb, disk,
> network, etc.).
In addtition to that we are also i
ark. As the result, IOMMU driver will block
> any translated requests from any device marked as untrusted.
>
> Cc: Jacob Pan
> Cc: Mika Westerberg
Reviewed-by: Mika Westerberg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Nov 29, 2018 at 06:51:49PM +0300, Mika Westerberg wrote:
> Recent systems with Thunderbolt ports may be utilizing IOMMU to prevent DMA
> attacks. This is different from the previous security level based scheme
> because the connected device cannot access system memory outsi
On Mon, Dec 03, 2018 at 06:28:00PM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 29, 2018 at 06:51:50PM +0300, Mika Westerberg wrote:
> > A malicious PCI device may use DMA to attack the system. An external
> > Thunderbolt port is a convenient point to attach such a device. The OS
>
d. In case this turns
out to cause performance issues we may selectively allow ATS based on
user decision but currently use big hammer and disable it completely to
be on the safe side.
[1] https://www.repository.cam.ac.uk/handle/1810/274352
Signed-off-by: Mika Westerberg
Reviewed-by: Ashok Raj
R
eat resulting when these GUIDs are treated equivalent.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Signed-off-by: Mika Westerberg
---
drivers/acpi/property.c | 11 +++
drivers/pci/pci-acpi.c | 1
e I did not change the code with the exception of few
comments and rename of the flag. Let me know if that's not the case
anymore.
Lu Baolu (1):
iommu/vt-d: Force IOMMU on for platform opt in hint
Mika Westerberg (3):
PCI / ACPI: Identify untrusted PCI devices
iommu/vt-d: Do
s/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Mika Westerberg
Reviewed-by: Yehezkel Bernat
---
.../ABI/testing/sysfs-bus-thunderbolt | 9 +
Documentation/admin-guide/thunderbolt.rst | 20 +++
drivers/thunderbol
[1]
https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf
[2]
https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Signed-off-by: Mika Westerberg
R
On Wed, Nov 28, 2018 at 12:24:27PM +0100, Rafael J. Wysocki wrote:
> I'm not sure if this is worth the extra complexity either, which is
> why I have no strong opinion here. :-)
>
> Maybe you can add a comment, next to the prp_guids[] definition, to
> explain that the GUIDs are made equivalent to
On Tue, Nov 27, 2018 at 06:14:43PM +0100, Rafael J. Wysocki wrote:
> > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> > index 8c7c4583b52d..4bdad32f62c8 100644
> > --- a/drivers/acpi/property.c
> > +++ b/drivers/acpi/property.c
> > @@ -31,6 +31,9 @@ static const guid_t prp_guids[]
On Mon, Nov 26, 2018 at 06:17:11PM -0600, Bjorn Helgaas wrote:
> Hi Mika,
Hi,
> On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote:
> > Recent systems with Thunderbolt ports may support IOMMU natively.
>
> This sentence doesn't make sense to me. There&
s/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Mika Westerberg
Reviewed-by: Yehezkel Bernat
---
.../ABI/testing/sysfs-bus-thunderbolt | 9 +
Documentation/admin-guide/thunderbolt.rst | 20 +++
drivers/thunderbol
d. In case this turns
out to cause performance issues we may selectively allow ATS based on
user decision but currently use big hammer and disable it completely to
be on the safe side.
[1] https://www.repository.cam.ac.uk/handle/1810/274352
Signed-off-by: Mika Westerberg
Reviewed-by: Ashok Raj
R
. This can be turned off by adding
"intel_iommu=off" in the kernel command line, if any problems are
found.
[1]
https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Signed-of
from Ashok, Joerg and Yehezkel. I'm assuming they still
apply because I did not change the code with the exception of few
comments and rename of the flag. Let me know if that's not the case
anymore.
Lu Baolu (1):
iommu/vt-d: Force IOMMU on for platform opt in hint
Mika Westerberg (
rated devices and may need to put behind full
IOMMU protection.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Signed-off-by: Mika Westerberg
---
drivers/acpi/property.c | 3 +++
drivers/pci/pci-acpi.c
On Fri, Nov 16, 2018 at 11:32:10AM +0200, Mika Westerberg wrote:
> On Fri, Nov 16, 2018 at 01:18:04AM -0800, Christoph Hellwig wrote:
> > On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote:
> > > FireWire is kind of different but there are connectors such as
> >
On Fri, Nov 16, 2018 at 01:18:04AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote:
> > FireWire is kind of different but there are connectors such as
> > ExpressCard and NVMe (over U.2 connector) which carry PCIe and are
> &g
On Thu, Nov 15, 2018 at 09:00:54PM +0200, Mika Westerberg wrote:
> On Thu, Nov 15, 2018 at 05:46:08PM +, Lorenzo Pieralisi wrote:
> > Do you really need to parse it if the dev->is_thunderbolt check is enough ?
>
> Yes, we need to parse it one way or another. dev->is_thun
On Thu, Nov 15, 2018 at 08:27:41PM +0100, Lukas Wunner wrote:
> On Thu, Nov 15, 2018 at 09:10:26PM +0200, Mika Westerberg wrote:
> > I was thinking we could cover all these with is_external filling them
> > based on the _DSD or some other means in the kernel.
> >
> >
On Thu, Nov 15, 2018 at 07:58:13PM +0200, Yehezkel Bernat wrote:
> From what I know, there are more devices that suffer from similar security
> issues like Thunderbolt, e.g. FireWire [1].
> My assumption is that the same protection may be applied to such devices too,
> even if currently it sounds l
On Thu, Nov 15, 2018 at 05:46:08PM +, Lorenzo Pieralisi wrote:
> Do you really need to parse it if the dev->is_thunderbolt check is enough ?
Yes, we need to parse it one way or another. dev->is_thunderbolt is
based on heuristics which do not apply anymore when the thing gets
integrated in the
On Thu, Nov 15, 2018 at 01:07:36PM +0100, Lukas Wunner wrote:
> On Thu, Nov 15, 2018 at 01:37:37PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote:
> > > I have strong objections to the way these bindings have been forced upon
&
On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote:
> I have strong objections to the way these bindings have been forced upon
> everybody; if that's the way *generic* ACPI bindings are specified I
> wonder why there still exists an ACPI specification and related working
> group.
>
On Tue, Nov 13, 2018 at 11:45:36AM +, Lorenzo Pieralisi wrote:
> On Tue, Nov 13, 2018 at 01:27:00PM +0200, Mika Westerberg wrote:
>
> [...]
>
> > > To be frank the concept (and Microsoft _DSD bindings) seems a bit vague
> > > and not thoroughly defined and I w
On Tue, Nov 13, 2018 at 05:38:53PM +0200, Yehezkel Bernat wrote:
> 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
On Tue, Nov 13, 2018 at 04:42:58PM +0200, Yehezkel Bernat wrote:
> On Tue, Nov 13, 2018 at 1:40 PM Mika Westerberg
> 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
> > >
On Tue, Nov 13, 2018 at 01:13:31PM +0200, Yehezkel Bernat wrote:
> On Tue, Nov 13, 2018 at 12:56 PM Mika Westerberg
> wrote:
> >
> > > Just one point:
> > > Have you considered the option to add this property per (TBT?) device?
> >
> > No. ;-)
> >
&
On Tue, Nov 13, 2018 at 09:54:24AM +0100, Joerg Roedel wrote:
> On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote:
> > Lu Baolu (1):
> > iommu/vt-d: Force IOMMU on for platform opt in hint
> >
> > Mika Westerberg (3):
> > PCI / ACPI: Identify ex
On Tue, Nov 13, 2018 at 10:56:36AM +, Lorenzo Pieralisi wrote:
> On Mon, Nov 12, 2018 at 07:02:03PM +0100, Lukas Wunner wrote:
> > On Mon, Nov 12, 2018 at 07:06:25PM +0300, Mika Westerberg wrote:
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.
On Mon, Nov 12, 2018 at 07:12:14PM +0100, Lukas Wunner wrote:
> On Mon, Nov 12, 2018 at 07:06:24PM +0300, Mika Westerberg wrote:
> > Recent systems shipping with Windows 10 version 1803 or newer may be
> > utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is
> &g
On Mon, Nov 12, 2018 at 06:59:02PM +0200, Yehezkel Bernat wrote:
> On Mon, Nov 12, 2018 at 6:06 PM Mika Westerberg
> wrote:
> >
> > Recent systems shipping with Windows 10 version 1803 or later may
> > support a feature called Kernel DMA protection [1]. In practice this
&g
On Mon, Nov 12, 2018 at 04:22:25PM +, mario.limoncie...@dell.com wrote:
> > +DMA protection utilizing IOMMU
> > +--
> > +Recent systems shipping with Windows 10 version 1803 or later may support a
> > +feature called `Kernel DMA Protection for Thunderbolt 3`_. This
lu
Signed-off-by: Mika Westerberg
---
drivers/iommu/dmar.c| 25 +
drivers/iommu/intel-iommu.c | 55 +++--
include/linux/dmar.h| 8 ++
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/io
s/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Mika Westerberg
---
.../ABI/testing/sysfs-bus-thunderbolt | 9
Documentation/admin-guide/thunderbolt.rst | 23 +++
drivers/thunderbolt/domain.c | 17 +++
mu/vt-d: Force IOMMU on for platform opt in hint
Mika Westerberg (3):
PCI / ACPI: Identify external PCI devices
iommu/vt-d: Do not enable ATS for external devices
thunderbolt: Export IOMMU based DMA protection support to userspace
.../ABI/testing/sysfs-bus-thunderbolt | 9 +++
ivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Signed-off-by: Mika Westerberg
---
drivers/acpi/property.c | 3 +++
drivers/pci/pci-acpi.c | 13 +
drivers/pci/probe.c | 23 +++
include/linux/pci.h | 1 +
4 files changed, 40 in
l. In case this turns
out to cause performance issues we may selectively allow ATS based on
user decision but currently use big hammer and disable it completely to
be on the safe side.
[1] https://www.repository.cam.ac.uk/handle/1810/274352
Signed-off-by: Mika Westerberg
---
drivers/iommu/intel-i
device could continue to work with only shared
> virtual memory impacted. So, let's go ahead with context mapping
> even the memory allocation for pasid table failed.
>
> Fixes: cc580e41260d ("iommu/vt-d: Per PCI device pasid table interfaces")
> Cc: Ashok Raj
> Cc:
On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote:
> From: Huang Rui
>
> Inspired by acpi platform bus type, to make driver "porting" more
> straightforward, this patch introduces ACPI support to the AMBA bus
> type. Instead of writing ACPI "glue" drivers for the exiting AMBA
> drive
65 matches
Mail list logo
