| Message ID | cover.1724694969.git.jan.kiszka@siemens.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | soc: ti: Add and use PVU on K3-AM65 for DMA isolation | expand |
On 26/08/2024 19:56, Jan Kiszka wrote: > Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system > against DMA-based attacks of external PCI devices. The AM65 is without > an IOMMU, but it comes with something close to it: the Peripheral > Virtualization Unit (PVU). > > The PVU was originally designed to establish static compartments via a > hypervisor, isolate those DMA-wise against each other and the host and > even allow remapping of guest-physical addresses. But it only provides > a static translation region, not page-granular mappings. Thus, it cannot > be handled transparently like an IOMMU. You keep developing on some old kernel. I noticed it on few patchsets last days. Please work on mainline. Best regards, Krzysztof
On 26.08.24 20:53, Krzysztof Kozlowski wrote: > On 26/08/2024 19:56, Jan Kiszka wrote: >> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >> against DMA-based attacks of external PCI devices. The AM65 is without >> an IOMMU, but it comes with something close to it: the Peripheral >> Virtualization Unit (PVU). >> >> The PVU was originally designed to establish static compartments via a >> hypervisor, isolate those DMA-wise against each other and the host and >> even allow remapping of guest-physical addresses. But it only provides >> a static translation region, not page-granular mappings. Thus, it cannot >> be handled transparently like an IOMMU. > > You keep developing on some old kernel. I noticed it on few patchsets > last days. Please work on mainline. > How did you come to this conclusion? This patch set was written for mainline, just rebased and tested again over next-20240826 before sending today. Jan
On 26/08/2024 21:25, Jan Kiszka wrote: > On 26.08.24 20:53, Krzysztof Kozlowski wrote: >> On 26/08/2024 19:56, Jan Kiszka wrote: >>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >>> against DMA-based attacks of external PCI devices. The AM65 is without >>> an IOMMU, but it comes with something close to it: the Peripheral >>> Virtualization Unit (PVU). >>> >>> The PVU was originally designed to establish static compartments via a >>> hypervisor, isolate those DMA-wise against each other and the host and >>> even allow remapping of guest-physical addresses. But it only provides >>> a static translation region, not page-granular mappings. Thus, it cannot >>> be handled transparently like an IOMMU. >> >> You keep developing on some old kernel. I noticed it on few patchsets >> last days. Please work on mainline. >> > > How did you come to this conclusion? This patch set was written for > mainline, just rebased and tested again over next-20240826 before > sending today. You send it to addresses you CANNOT get from mainline kernel. There is no way mainline kernel get_maintainers.pl produces them. Best regards, Krzysztof
On 27.08.24 08:35, Krzysztof Kozlowski wrote: > On 26/08/2024 21:25, Jan Kiszka wrote: >> On 26.08.24 20:53, Krzysztof Kozlowski wrote: >>> On 26/08/2024 19:56, Jan Kiszka wrote: >>>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >>>> against DMA-based attacks of external PCI devices. The AM65 is without >>>> an IOMMU, but it comes with something close to it: the Peripheral >>>> Virtualization Unit (PVU). >>>> >>>> The PVU was originally designed to establish static compartments via a >>>> hypervisor, isolate those DMA-wise against each other and the host and >>>> even allow remapping of guest-physical addresses. But it only provides >>>> a static translation region, not page-granular mappings. Thus, it cannot >>>> be handled transparently like an IOMMU. >>> >>> You keep developing on some old kernel. I noticed it on few patchsets >>> last days. Please work on mainline. >>> >> >> How did you come to this conclusion? This patch set was written for >> mainline, just rebased and tested again over next-20240826 before >> sending today. > > You send it to addresses you CANNOT get from mainline kernel. There is > no way mainline kernel get_maintainers.pl produces them. > That is likely due to that I didn't re-run the get_maintainers.pl for all areas of changes but rather reused an address list from a slightly older posting, sorry. IOW, your assumption is still not correct when it comes to code. Jan
On 27/08/2024 11:22, Jan Kiszka wrote: > On 27.08.24 08:35, Krzysztof Kozlowski wrote: >> On 26/08/2024 21:25, Jan Kiszka wrote: >>> On 26.08.24 20:53, Krzysztof Kozlowski wrote: >>>> On 26/08/2024 19:56, Jan Kiszka wrote: >>>>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >>>>> against DMA-based attacks of external PCI devices. The AM65 is without >>>>> an IOMMU, but it comes with something close to it: the Peripheral >>>>> Virtualization Unit (PVU). >>>>> >>>>> The PVU was originally designed to establish static compartments via a >>>>> hypervisor, isolate those DMA-wise against each other and the host and >>>>> even allow remapping of guest-physical addresses. But it only provides >>>>> a static translation region, not page-granular mappings. Thus, it cannot >>>>> be handled transparently like an IOMMU. >>>> >>>> You keep developing on some old kernel. I noticed it on few patchsets >>>> last days. Please work on mainline. >>>> >>> >>> How did you come to this conclusion? This patch set was written for >>> mainline, just rebased and tested again over next-20240826 before >>> sending today. >> >> You send it to addresses you CANNOT get from mainline kernel. There is >> no way mainline kernel get_maintainers.pl produces them. >> > > That is likely due to that I didn't re-run the get_maintainers.pl for > all areas of changes but rather reused an address list from a slightly > older posting, sorry. > > IOW, your assumption is still not correct when it comes to code. Sure, I see results and I am guessing the reason. Keeping the list static is not the approach you should be using, as seen here. It does not make even sense, because then you need to keep several lists per different subsystems or you CC unrelated people (don't). Just use simple wrapper over git send email, b4 or patman. https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91 Best regards, Krzysztof
On 27.08.24 14:44, Krzysztof Kozlowski wrote: > On 27/08/2024 11:22, Jan Kiszka wrote: >> On 27.08.24 08:35, Krzysztof Kozlowski wrote: >>> On 26/08/2024 21:25, Jan Kiszka wrote: >>>> On 26.08.24 20:53, Krzysztof Kozlowski wrote: >>>>> On 26/08/2024 19:56, Jan Kiszka wrote: >>>>>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >>>>>> against DMA-based attacks of external PCI devices. The AM65 is without >>>>>> an IOMMU, but it comes with something close to it: the Peripheral >>>>>> Virtualization Unit (PVU). >>>>>> >>>>>> The PVU was originally designed to establish static compartments via a >>>>>> hypervisor, isolate those DMA-wise against each other and the host and >>>>>> even allow remapping of guest-physical addresses. But it only provides >>>>>> a static translation region, not page-granular mappings. Thus, it cannot >>>>>> be handled transparently like an IOMMU. >>>>> >>>>> You keep developing on some old kernel. I noticed it on few patchsets >>>>> last days. Please work on mainline. >>>>> >>>> >>>> How did you come to this conclusion? This patch set was written for >>>> mainline, just rebased and tested again over next-20240826 before >>>> sending today. >>> >>> You send it to addresses you CANNOT get from mainline kernel. There is >>> no way mainline kernel get_maintainers.pl produces them. >>> >> >> That is likely due to that I didn't re-run the get_maintainers.pl for >> all areas of changes but rather reused an address list from a slightly >> older posting, sorry. >> >> IOW, your assumption is still not correct when it comes to code. > > Sure, I see results and I am guessing the reason. Keeping the list > static is not the approach you should be using, as seen here. It does > not make even sense, because then you need to keep several lists per > different subsystems or you CC unrelated people (don't). Just use simple > wrapper over git send email, b4 or patman. > > https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91 > ha Those options are useful, unconditional automated usage of the script is not when you might be targeting multiple subsystems in a series (not that uncommon in our scenarios). That's why shaping/confirming the final list remains a manual step for me. But I'll improve on keeping it updated. Thanks, Jan
On 27/08/2024 15:38, Jan Kiszka wrote: > On 27.08.24 14:44, Krzysztof Kozlowski wrote: >> On 27/08/2024 11:22, Jan Kiszka wrote: >>> On 27.08.24 08:35, Krzysztof Kozlowski wrote: >>>> On 26/08/2024 21:25, Jan Kiszka wrote: >>>>> On 26.08.24 20:53, Krzysztof Kozlowski wrote: >>>>>> On 26/08/2024 19:56, Jan Kiszka wrote: >>>>>>> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system >>>>>>> against DMA-based attacks of external PCI devices. The AM65 is without >>>>>>> an IOMMU, but it comes with something close to it: the Peripheral >>>>>>> Virtualization Unit (PVU). >>>>>>> >>>>>>> The PVU was originally designed to establish static compartments via a >>>>>>> hypervisor, isolate those DMA-wise against each other and the host and >>>>>>> even allow remapping of guest-physical addresses. But it only provides >>>>>>> a static translation region, not page-granular mappings. Thus, it cannot >>>>>>> be handled transparently like an IOMMU. >>>>>> >>>>>> You keep developing on some old kernel. I noticed it on few patchsets >>>>>> last days. Please work on mainline. >>>>>> >>>>> >>>>> How did you come to this conclusion? This patch set was written for >>>>> mainline, just rebased and tested again over next-20240826 before >>>>> sending today. >>>> >>>> You send it to addresses you CANNOT get from mainline kernel. There is >>>> no way mainline kernel get_maintainers.pl produces them. >>>> >>> >>> That is likely due to that I didn't re-run the get_maintainers.pl for >>> all areas of changes but rather reused an address list from a slightly >>> older posting, sorry. >>> >>> IOW, your assumption is still not correct when it comes to code. >> >> Sure, I see results and I am guessing the reason. Keeping the list >> static is not the approach you should be using, as seen here. It does >> not make even sense, because then you need to keep several lists per >> different subsystems or you CC unrelated people (don't). Just use simple >> wrapper over git send email, b4 or patman. >> >> https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91 >> ha > > Those options are useful, unconditional automated usage of the script is > not when you might be targeting multiple subsystems in a series (not > that uncommon in our scenarios). That's why shaping/confirming the final > list remains a manual step for me. But I'll improve on keeping it updated. For that use git send-email identity hack. And anyway it still does not apply to patchset here which should have been sent to everyone or SPLIT. Putting DTS in the middle is a no-go, because it suggests there is depednency and you CANNOT have such dependency. Best regards, Krzysztof
Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system against DMA-based attacks of external PCI devices. The AM65 is without an IOMMU, but it comes with something close to it: the Peripheral Virtualization Unit (PVU). The PVU was originally designed to establish static compartments via a hypervisor, isolate those DMA-wise against each other and the host and even allow remapping of guest-physical addresses. But it only provides a static translation region, not page-granular mappings. Thus, it cannot be handled transparently like an IOMMU. Now, to use the PVU for the purpose of isolated PCI devices from the Linux host, this series takes a different approach. It defines a restricted-dma-pool for the PCI host, using swiotlb to map all DMA buffers from a static memory carve-out. And to enforce that the devices actually follow this, a special PVU soc driver is introduced. The driver permits access to the GIC ITS and otherwise waits for other drivers that detect devices with constrained DMA to register pools with the PVU. For the AM65, the first (and possibly only) driver where this is introduced is the pci-keystone host controller. Finally, this series configures the IOT2050 devices (all have MiniPCIe or M.2 extension slots) to make use of this protection scheme. Due to the cross-cutting nature of these changes, multiple subsystems are affected. However, I wanted to present the whole thing in one series to allow everyone to review with the complete picture in hands. If preferred, I can also split the series up, of course. Jan CC: Bjorn Helgaas <bhelgaas@google.com> CC: "Krzysztof Wilczyński" <kw@linux.com> CC: linux-pci@vger.kernel.org CC: Lorenzo Pieralisi <lpieralisi@kernel.org> Jan Kiszka (5): dt-bindings: soc: ti: Add AM65 peripheral virtualization unit soc: ti: Add IOMPU-like PVU driver arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes PCI: keystone: Add supported for PVU-based DMA isolation on AM654 arm64: dts: ti: iot2050: Enforce DMA isolation for devices behind PCI RC .../bindings/soc/ti/ti,am654-pvu.yaml | 48 ++ .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 32 ++ arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 18 +- drivers/pci/controller/dwc/pci-keystone.c | 101 ++++ drivers/soc/ti/Kconfig | 4 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/ti-pvu.c | 487 ++++++++++++++++++ include/linux/ti-pvu.h | 11 + 8 files changed, 698 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml create mode 100644 drivers/soc/ti/ti-pvu.c create mode 100644 include/linux/ti-pvu.h