linux-kernel - Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

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: <6e457227-ca06-2998-4ffa-a58ab171ce32@arm.com>
Date:   Wed, 30 Oct 2019 15:35:55 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Will Deacon <will@...nel.org>, iommu@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org
Cc:     Joerg Roedel <joro@...tes.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On 30/10/2019 14:51, Will Deacon wrote:
> Hi all,
> 
> As part of the work to enable a "Generic Kernel Image" across multiple
> Android devices, there is a need to seperate shared, core kernel code
> from modular driver code that may not be needed by all SoCs. This means
> building IOMMU drivers as modules.
> 
> It turns out that most of the groundwork has already been done to enable
> the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig;
> with a few symbols exported from the IOMMU/PCI core, everything builds
> nicely out of the box. The one exception is support for the legacy SMMU
> DT binding, which is not in widespread use and has never worked with
> modules, so we can simply remove that when building as a module rather
> than try to paper over it with even more hacks.
> 
> Obviously you need to be careful about using IOMMU drivers as modules,
> since late loading of the driver for an IOMMU serving active DMA masters
> is going to end badly in many cases. On Android, we're using device links
> to ensure that the IOMMU probes first.

Out of curiosity, which device links are those? Clearly not the RPM 
links created by the IOMMU drivers themselves... Is this some special 
Android magic, or is there actually a chance of replacing all the 
of_iommu_configure() machinery with something more generic?

Robin.

> 
> Comments welcome,
> 
> Will
> 
> Cc: Robin Murphy <robin.murphy@....com>
> Cc: Joerg Roedel <joro@...tes.org>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> 
> --->8
> 
> Will Deacon (7):
>    drivers/iommu: Export core IOMMU API symbols to permit modular drivers
>    iommu/of: Request ACS from the PCI core when configuring IOMMU linkage
>    PCI: Export pci_ats_disabled() as a GPL symbol to modules
>    Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"
>    iommu/arm-smmu-v3: Allow building as a module
>    Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"
>    iommu/arm-smmu: Allow building as a module
> 
>   drivers/iommu/Kconfig         | 16 ++++++-
>   drivers/iommu/arm-smmu-impl.c |  6 +++
>   drivers/iommu/arm-smmu-v3.c   | 26 +++++++----
>   drivers/iommu/arm-smmu.c      | 86 +++++++++++++++++++++--------------
>   drivers/iommu/iommu-sysfs.c   |  5 ++
>   drivers/iommu/iommu.c         |  8 ++++
>   drivers/iommu/of_iommu.c      |  1 +
>   drivers/pci/pci.c             |  1 +
>   8 files changed, 102 insertions(+), 47 deletions(-)
>