linux-kernel - Re: [PATCH v3 09/10] iommu/dart: Exclude MSI doorbell from PCIe device IOVA range

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: <87ilyzbjw8.wl-maz@kernel.org>
Date:   Fri, 17 Sep 2021 11:01:43 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     "Sven Peter" <sven@...npeter.dev>
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, "Bjorn Helgaas" <bhelgaas@...gle.com>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Lorenzo Pieralisi" <lorenzo.pieralisi@....com>,
        Krzysztof Wilczyński <kw@...ux.com>,
        "Alyssa Rosenzweig" <alyssa@...enzweig.io>,
        "Stan Skowronek" <stan@...ellium.com>,
        "Mark Kettenis" <kettenis@...nbsd.org>,
        "Hector Martin" <marcan@...can.st>,
        "Robin Murphy" <Robin.Murphy@....com>, kernel-team@...roid.com
Subject: Re: [PATCH v3 09/10] iommu/dart: Exclude MSI doorbell from PCIe device IOVA range

On Tue, 14 Sep 2021 14:54:07 +0100,
"Sven Peter" <sven@...npeter.dev> wrote:
> 
> 
> 
> On Mon, Sep 13, 2021, at 20:25, Marc Zyngier wrote:
> > The MSI doorbell on Apple HW can be any address in the low 4GB
> > range. However, the MSI write is matched by the PCIe block before
> > hitting the iommu. It must thus be excluded from the IOVA range
> > that is assigned to any PCIe device.
> > 
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> 
> It's not pretty but I'm not aware of any better solution and this should
> work as long as these two are always paired. With the small nit below
> addressed:
> 
> Reviewed-by: Sven Peter <sven@...npeter.dev>
> 
> > ---
> >  drivers/iommu/apple-dart.c          | 25 +++++++++++++++++++++++++
> >  drivers/pci/controller/Kconfig      |  5 +++++
> >  drivers/pci/controller/pcie-apple.c |  4 +++-
> >  3 files changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
> > index 559db9259e65..d1456663688e 100644
> > --- a/drivers/iommu/apple-dart.c
> > +++ b/drivers/iommu/apple-dart.c
> > @@ -721,6 +721,29 @@ static int apple_dart_def_domain_type(struct device *dev)
> >  	return 0;
> >  }
> >  
> > +#define DOORBELL_ADDR	(CONFIG_PCIE_APPLE_MSI_DOORBELL_ADDR & PAGE_MASK)
> > +
> > +static void apple_dart_get_resv_regions(struct device *dev,
> > +					struct list_head *head)
> > +{
> > +#ifdef CONFIG_PCIE_APPLE
> 
> I think using IS_ENABLED would be better here in case the pcie
> driver is built as a module which would then only define
> CONFIG_PCIE_APPLE_MODULE AIUI.

You're right, this isn't great. However, IS_ENABLED() still results in
the evaluation of the following code by the compiler, even if it would
be dropped by the optimiser.

I resorted to the following construct:

<quote>
#ifndef CONFIG_PCIE_APPLE_MSI_DOORBELL_ADDR
/* Keep things compiling when CONFIG_PCI_APPLE isn't selected */
#define CONFIG_PCIE_APPLE_MSI_DOORBELL_ADDR	0
#endif
#define DOORBELL_ADDR	(CONFIG_PCIE_APPLE_MSI_DOORBELL_ADDR & PAGE_MASK)

static void apple_dart_get_resv_regions(struct device *dev,
					struct list_head *head)
{
	if (IS_ENABLED(CONFIG_PCIE_APPLE) && dev_is_pci(dev)) {
</quote>

which is ugly, but works. The alternative is, of course, to add a new
include file for one single value, which I find even worse.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.