Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
Reviewed-by: Lu Baolu
Acked
us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
---
v7: * Update the comment, based on feedback.
v6: * Take care of Bjorn's comments:
- Update the commit log
On Tue, Apr 26, 2022 at 4:15 AM Robin Murphy wrote:
>
> On 2022-04-26 01:06, Rajat Jain via iommu wrote:
> > The "DmaProperty" is supported and currently documented and used by
> > Microsoft [link 1 below], to flag internal PCIe root ports that need
> > DMA
us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
---
v6: * Take care of Bjorn's comments:
- Update the commit log
- Rename to pci_dev_has_dma_property()
Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
---
v6
Hello Bjorn,
On Thu, Apr 7, 2022 at 12:17 PM Bjorn Helgaas wrote:
>
> In subject,
>
> PCI/ACPI: ...
>
> would be consistent with previous history (at least things coming
> through the PCI tree :)).
Will do.
>
> On Fri, Mar 25, 2022 at 11:46:08AM -0700, Rajat Jain
Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerberg
---
v5: Use "untruste
protection-for-thunderbolt
Support the "DmaProperty" with the same semantics. This is useful for
internal PCI devices that do not hang off a PCIe rootport, but offer
an attack surface for DMA attacks (e.g. internal network devices).
Signed-off-by: Rajat Jain
Reviewed-by: Mika Westerber
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 more clear, that the device can execute DMA
protection-for-thunderbolt
Support the "DmaProperty" with the same semantics. This is useful for
internal PCI devices that do not hang off a PCIe rootport, but offer
an attack surface for DMA attacks (e.g. internal network devices).
Signed-off-by: Rajat Jain
---
v4: * Add the GUID.
* U
Rename the field to make it more clear, that the device can execute DMA
attacks on the system, and thus the system may need protection from
such attacks from this device.
No functional change intended.
Signed-off-by: Rajat Jain
---
v4: Initial version, created based on comments on other patch
I'm wondering why I don't see v7 on these patches on patchwork (these
patches on
https://lore.kernel.org/patchwork/project/lkml/list/?series==27643)
?
On Sun, Aug 29, 2021 at 10:00 PM David Stevens wrote:
>
> This patch set includes various fixes for dma-iommu's swiotlb bounce
> buffers for
On Mon, Aug 9, 2021 at 12:59 PM Robin Murphy wrote:
>
> On 2021-08-09 20:05, Rajat Jain wrote:
> > On Wed, Aug 4, 2021 at 10:16 AM Robin Murphy wrote:
> >>
> >> Factor out flush queue setup from the initial domain init so that we
> >> can potentially trigg
On Wed, Aug 4, 2021 at 10:16 AM Robin Murphy wrote:
>
> Factor out flush queue setup from the initial domain init so that we
> can potentially trigger it from sysfs later on in a domain's lifetime.
>
> Reviewed-by: Lu Baolu
> Reviewed-by: John Garry
> Signed-off-by: Robin Murphy
> ---
>
Hi Rob,
On Mon, Aug 2, 2021 at 5:09 PM Rajat Jain wrote:
>
> Hi Robin, Doug,
>
> On Wed, Jul 14, 2021 at 8:14 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy wrote:
> > >
> > > On 2021-07-08 15:36,
Hi Robin, Doug,
On Wed, Jul 14, 2021 at 8:14 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy wrote:
> >
> > On 2021-07-08 15:36, Doug Anderson wrote:
> > [...]
> > >> Or document for the users that want performance how to
> > >> change the setting, so that they
On Mon, Jun 21, 2021 at 4:53 PM Douglas Anderson wrote:
>
> In the patch ("drivers: base: Add bits to struct device to control
> iommu strictness") we add the ability for devices to tell us about
> their IOMMU strictness requirements. Let's now take that into account
> in the IOMMU layer.
>
> A
Only field renaming. No functional change intended.
Signed-off-by: Rajat Jain
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/intel/iommu.c | 2 +-
drivers/iommu/iommu.c | 2 +-
drivers/pci/ats.c | 2 +-
drivers/pci/pci.c | 2 +-
drivers/pci/
On Wed, Sep 23, 2020 at 9:19 AM Raj, Ashok wrote:
>
> Hi Bjorn
>
>
> On Wed, Sep 23, 2020 at 11:03:27AM -0500, Bjorn Helgaas wrote:
> > [+cc IOMMU and NVMe folks]
> >
> > Sorry, I forgot to forward this to linux-pci when it was first
> > reported.
> >
> > Apparently this happens with v5.9-rc3,
Hello Bjorn,
On Tue, Jul 14, 2020 at 1:19 PM Rajat Jain wrote:
>
> On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
> >
> > On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > > O
Hello Bjorn,
On Mon, Aug 17, 2020 at 3:50 PM Rajat Jain wrote:
>
> Hello Bjorn,
>
>
> On Sat, Aug 1, 2020 at 5:30 PM Rajat Jain wrote:
> >
> > Hi Bjorn,
> >
> >
> > On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
> > >
&
Hello Bjorn,
On Sat, Aug 1, 2020 at 5:30 PM Rajat Jain wrote:
>
> Hi Bjorn,
>
>
> On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
> >
> > On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> > >
> > > The ACS "Translation Blocking" bit
Hi Bjorn,
On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
>
> On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> >
> > The ACS "Translation Blocking" bit blocks the translated addresses from
> > the devices. We don't expect such traffic from devices
Hi Bjorn,
On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS e
by default for all devices, and it stays enabled until
atleast one of the devices downstream wants to enable ATS. It gets
disabled to enable ATS on a device downstream it, and then gets enabled
back on once all the downstream devices don't need ATS.
Signed-off-by: Rajat Jain
---
Note that I'
On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
>
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS enabled,
> i
On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
>
> On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jul 07
On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
>
> On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jul 07
Hello,
On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
>
> Hi Bjorn
>
>
> On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote:
> > > When enabling ACS, enable translation bloc
Currently ACS capabiity is being looked up at a number of places. Read and
store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v4: No change
v3: fix commit log, remove forward declation of static function
v2: Commit log cosmetic changes
drivers/pci
Move pci_enable_acs() and the functions it depends on, further up in the
source code to avoid having to forward declare it when we make it static
in near future (next patch).
No functional changes intended.
Signed-off-by: Rajat Jain
---
v4: Same as v3
v3: Initial version of the patch, created
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v4: Add braces to avoid warning from kernel robot
print warning for only external-facing devices.
v3: print warning if ACS_TB not supported on external-facing
kernel.org/linux-pci/20200610230906.GA1528594@bjorn-Precision-5520/
Signed-off-by: Rajat Jain
---
v4: No change
v3: * fix commit log and minor code comment
* Don't check for "ExternalFacingPort" on PCI_EXP_TYPE_DOWNSTREAM
* Check only for pdev->external_facing in iommu.c
v2: cosmeti
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v3: print warning if ACS_TB not supported on external-facing/untrusted ports.
Minor code comments fixes.
v2: Commit log change
drivers/pci/pci.c| 7
On Wed, Jul 1, 2020 at 10:23 PM Oliver O'Halloran wrote:
>
> On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
> >
> > *snip*
> >
> > > > I guess it would make sense to have an attribute for user space to
> > > > write to in order to make the ke
kernel.org/linux-pci/20200610230906.GA1528594@bjorn-Precision-5520/
Signed-off-by: Rajat Jain
---
v3: * fix commit log and minor code comment
* Don't check for "ExternalFacingPort" on PCI_EXP_TYPE_DOWNSTREAM
* Check only for pdev->external_facing in iommu.c
v2: cosmetic changes in
Move pci_enable_acs() and the functions it depends on, further up in the
source code to avoid having to forward declare it when we make it static
in near future (next patch).
No functional changes intended.
Signed-off-by: Rajat Jain
---
v3: Initial version of the patch, created per Bjorn's
Currently ACS capabiity is being looked up at a number of places. Read and
store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v3: fix commit log, remove forward declation of static function
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2
Hello Bjorn,
On Mon, Jul 6, 2020 at 4:30 PM Bjorn Helgaas wrote:
>
> On Mon, Jul 06, 2020 at 03:31:47PM -0700, Rajat Jain wrote:
> > On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
> > > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
&
On Tue, Jun 30, 2020 at 1:02 AM Greg Kroah-Hartman
wrote:
>
> On Mon, Jun 29, 2020 at 09:49:40PM -0700, Rajat Jain wrote:
> > device_attach() returning failure indicates a driver error while trying to
> > probe the device. In such a scenario, the PCI device should still be added
lways")
Signed-off-by: Rajat Jain
Reviewed-by: Greg Kroah-Hartman
---
Resending to stable, independent from other patches per Greg's suggestion
v2: Add Greg's reviewed by, fix commit log
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c
On Mon, Jul 6, 2020 at 10:07 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
>
On Mon, Jul 6, 2020 at 9:45 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
>
Hello,
On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > The "ExternalFacing" devices (root ports) are still internal devices that
> > sit on the internal system fabric and thus trusted. Currentl
On Sat, Jul 4, 2020 at 4:44 AM Pavel Machek wrote:
>
> Hi!
>
> > * The first 3 patches tighten the PCI security using ACS, and take care
> > of a border case.
> > * The 4th patch takes care of PCI bug.
> > * 5th and 6th patches expose a device's location into the sysfs to allow
> > admin to
Hi Bjorn,
Thanks for taking a look.
On Mon, Jul 6, 2020 at 8:58 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:37PM -0700, Rajat Jain wrote:
> > Currently this is being looked up at a number of places. Read and store it
> > once at bootup so that it can be
:34PM +0200, Rafael J. Wysocki wrote:
> > > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > > > > On Mon, Jun 29, 2020 at
as an ABI elsewhere, so settled for "site"). Individual buses
that want to support this new attribute can opt-in by setting a flag in
bus_type, and then populating the location of device while enumerating
it.
Signed-off-by: Rajat Jain
---
v2: (Initial version)
drivers/bas
to clear drivers_autoprobe.
Another problem is that even with drivers_autoprobe=0, the hot-added
PCI devices are bound to drivers because PCI explicitly calls
device_attach() asking driver core to find and attach a driver. This
patch helps with both of these problems.
Signed-off-by: Rajat Jain
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v2: Commit log change
drivers/pci/pci.c| 4
drivers/pci/quirks.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b
lways")
Signed-off-by: Rajat Jain
Reviewed-by: Greg Kroah-Hartman
---
v2: Cosmetic change in commit log.
Add Greg's "reviewed-by"
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 8e40b3e6da77d..
rmware info. Any
device not behind the "ExternalFacing" bridges are marked internal and
the ones behind such bridges are markes external.
Signed-off-by: Rajat Jain
---
v2: (Initial version)
drivers/iommu/intel/iommu.c | 31 +--
drivers/pci/ats.c | 2 +-
am devices as "untrusted". The
external-facing devices themselves are left as "trusted". This was
discussed here: https://lkml.org/lkml/2020/6/10/1049
Signed-off-by: Rajat Jain
---
v2: cosmetic changes in commit log
drivers/iommu/intel/iommu.c | 2 +-
drivers/pci/of.c|
Currently this is being looked up at a number of places. Read and store it
once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2
bug.
* 5th and 6th patches expose a device's location into the sysfs to allow
admin to make decision based on that.
* 7th patch is to ensure that the external devices don't bind to drivers
during boot.
Rajat Jain (7):
PCI: Keep the ACS capability offset in device
PCI: Set "untrusted&
led
>
> On Thu, Jun 25, 2020 at 05:27:09PM -0700, Rajat Jain wrote:
> > device_attach() returning failure indicates a driver error
> > while trying to probe the device. In such a scenario, the PCI
> > device should still be added in the system and be visible to
> >
Hello,
Thanks for taking a look.
On Fri, Jun 26, 2020 at 7:18 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> > Introduce a PCI parameter that disables the automatic attachment of
> > untrusted devices to their drivers.
> >
Introduce a PCI parameter that disables the automatic attachment of
untrusted devices to their drivers.
Signed-off-by: Rajat Jain
---
Context:
I set out to implement the approach outlined in
https://lkml.org/lkml/2020/6/9/1331
https://lkml.org/lkml/2020/6/15/1453
But to my surprise
lways")
Signed-off-by: Rajat Jain
---
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 8e40b3e6da77d..3cef835b375fd 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -322,12 +322,8 @@ void pci_bus_add_dev
Hi Ashok,
On Fri, Jun 19, 2020 at 9:10 AM Raj, Ashok wrote:
>
> Hi Rajat
>
>
> On Mon, Jun 15, 2020 at 06:17:41PM -0700, Rajat Jain wrote:
> > When enabling ACS, currently the bit "translation blocking" was
> > not getting changed at all. Set it to disab
Hi Bjorn, All,
Thank you so much for your helpful review and inputs.
On Mon, Jun 15, 2020 at 6:17 PM Rajat Jain wrote:
>
> This is needed to allow the userspace to determine when an untrusted
> device has been added, and thus allowing it to bind the driver manually
> to it, if
Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming in.
On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote:
>
> Hi Greg,
>
>
> On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Ja
Hello,
On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
wrote:
>
> On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote:
> &g
Hi Greg, Christoph,
On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote:
>
> On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> > Need clarification. The flag "untrusted" is currently a part of
> > pci_dev struct, and is populated withi
On Tue, Jun 16, 2020 at 12:32 AM Christoph Hellwig wrote:
>
> On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain via iommu wrote:
> > This is needed to allow the userspace to determine when an untrusted
> > device has been added, and thus allowing it to bind t
d then use it to mark any downstream devices as "untrusted". The
external-facing devices themselves are left as "trusted". This was
discussed here: https://lkml.org/lkml/2020/6/10/1049
Signed-off-by: Rajat Jain
---
drivers/iommu/intel/iommu.c | 2 +-
drivers/pci/of.c
This is needed to allow the userspace to determine when an untrusted
device has been added, and thus allowing it to bind the driver manually
to it, if it so wishes. This is being done as part of the approach
discussed at https://lkml.org/lkml/2020/6/9/1331
Signed-off-by: Rajat Jain
---
drivers
Currently this is being looked up at a number of places. Read
and store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2 +-
drivers/pci/probe.c | 2
When enabling ACS, currently the bit "translation blocking" was
not getting changed at all. Set it to disable translation blocking
too for all external facing or untrusted devices. This is OK
because ATS is only allowed on internal devces.
Signed-off-by: Rajat Jain
---
drivers/pci/pci
-by: Rajat Jain
Acked-by: Lu Baolu
Reviewed-by: Ashok Raj
---
v4: - Add Ashok Raj's "Reviewed-by"
- Use pci_info() and split debug print cleanly into 2 statements.
v3: - Separate out the warning mesage in a function to be called from
other places. Change the warning string as
On Tue, Jun 2, 2020 at 10:30 PM Mika Westerberg
wrote:
>
> 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,
> > +
On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani wrote:
>
> Hi Rajat,
Hi Prashant, thanks for taking a look.
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devic
-by: Rajat Jain
Acked-by: Lu Baolu
---
v3: - Separate out the warning mesage in a function to be called from
other places. Change the warning string as suggested.
v2: - Change the warning print strings.
- Add Lu Baolu's acknowledgement.
drivers/iommu/intel-iommu.c | 37
Hi MIka,
Thanks for taking a look.
On Tue, Jun 2, 2020 at 2:50 AM Mika Westerberg
wrote:
>
> 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
-by: Rajat Jain
Acked-by: Lu Baolu
---
V2: - Change the warning print strings.
- Add Lu Baolu's acknowledgement.
drivers/iommu/intel-iommu.c | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
-by: Rajat Jain
---
drivers/iommu/intel-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..f2a480168a02f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
76 matches
Mail list logo
