| 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
| ||
|
Message-ID: <AM5PR0401MB2545F1BFDFD57FC8D48E45C59A630@AM5PR0401MB2545.eurprd04.prod.outlook.com>
Date: Fri, 6 Jan 2017 09:31:03 +0000
From: Bharat Bhushan <bharat.bhushan@....com>
To: Marc Zyngier <marc.zyngier@....com>,
Auger Eric <eric.auger@...hat.com>,
"eric.auger.pro@...il.com" <eric.auger.pro@...il.com>,
"christoffer.dall@...aro.org" <christoffer.dall@...aro.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"will.deacon@....com" <will.deacon@....com>,
"joro@...tes.org" <joro@...tes.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"jason@...edaemon.net" <jason@...edaemon.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"drjones@...hat.com" <drjones@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"pranav.sawargaonkar@...il.com" <pranav.sawargaonkar@...il.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"punit.agrawal@....com" <punit.agrawal@....com>,
Diana Madalina Craciun <diana.craciun@....com>,
"gpkulkarni@...il.com" <gpkulkarni@...il.com>,
"shankerd@...eaurora.org" <shankerd@...eaurora.org>,
"geethasowjanya.akula@...il.com" <geethasowjanya.akula@...il.com>
Subject: RE: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain
level
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier@....com]
> Sent: Friday, January 06, 2017 2:50 PM
> To: Auger Eric <eric.auger@...hat.com>; Bharat Bhushan
> <bharat.bhushan@....com>; eric.auger.pro@...il.com;
> christoffer.dall@...aro.org; robin.murphy@....com;
> alex.williamson@...hat.com; will.deacon@....com; joro@...tes.org;
> tglx@...utronix.de; jason@...edaemon.net; linux-arm-
> kernel@...ts.infradead.org
> Cc: kvm@...r.kernel.org; drjones@...hat.com; linux-
> kernel@...r.kernel.org; pranav.sawargaonkar@...il.com;
> iommu@...ts.linux-foundation.org; punit.agrawal@....com; Diana Madalina
> Craciun <diana.craciun@....com>; gpkulkarni@...il.com;
> shankerd@...eaurora.org; geethasowjanya.akula@...il.com
> Subject: Re: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq
> domain level
>
> On 06/01/17 09:08, Auger Eric wrote:
> > Hi Bharat
> >
> > On 06/01/2017 09:50, Bharat Bhushan wrote:
> >> Hi Eric,
> >>
> >>> -----Original Message-----
> >>> From: Eric Auger [mailto:eric.auger@...hat.com]
> >>> Sent: Friday, January 06, 2017 12:35 AM
> >>> To: eric.auger@...hat.com; eric.auger.pro@...il.com;
> >>> christoffer.dall@...aro.org; marc.zyngier@....com;
> >>> robin.murphy@....com; alex.williamson@...hat.com;
> >>> will.deacon@....com; joro@...tes.org; tglx@...utronix.de;
> >>> jason@...edaemon.net; linux-arm-kernel@...ts.infradead.org
> >>> Cc: kvm@...r.kernel.org; drjones@...hat.com; linux-
> >>> kernel@...r.kernel.org; pranav.sawargaonkar@...il.com;
> >>> iommu@...ts.linux-foundation.org; punit.agrawal@....com; Diana
> >>> Madalina Craciun <diana.craciun@....com>; gpkulkarni@...il.com;
> >>> shankerd@...eaurora.org; Bharat Bhushan
> <bharat.bhushan@....com>;
> >>> geethasowjanya.akula@...il.com
> >>> Subject: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq
> >>> domain level
> >>>
> >>> In case the IOMMU translates MSI transactions (typical case on ARM),
> >>> we check MSI remapping capability at IRQ domain level. Otherwise it
> >>> is checked at IOMMU level.
> >>>
> >>> At this stage the arm-smmu-(v3) still advertise the
> >>> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
> removed
> >>> in subsequent patches.
> >>>
> >>> Signed-off-by: Eric Auger <eric.auger@...hat.com>
> >>>
> >>> ---
> >>>
> >>> v6: rewrite test
> >>> ---
> >>> drivers/vfio/vfio_iommu_type1.c | 9 ++++++---
> >>> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >>> b/drivers/vfio/vfio_iommu_type1.c index b473ef80..fa0b5c4 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -40,6 +40,7 @@
> >>> #include <linux/mdev.h>
> >>> #include <linux/notifier.h>
> >>> #include <linux/dma-iommu.h>
> >>> +#include <linux/irqdomain.h>
> >>>
> >>> #define DRIVER_VERSION "0.2"
> >>> #define DRIVER_AUTHOR "Alex Williamson
> >>> <alex.williamson@...hat.com>"
> >>> @@ -1208,7 +1209,7 @@ static int
> vfio_iommu_type1_attach_group(void
> >>> *iommu_data,
> >>> struct vfio_domain *domain, *d;
> >>> struct bus_type *bus = NULL, *mdev_bus;
> >>> int ret;
> >>> - bool resv_msi;
> >>> + bool resv_msi, msi_remap;
> >>> phys_addr_t resv_msi_base;
> >>>
> >>> mutex_lock(&iommu->lock);
> >>> @@ -1284,8 +1285,10 @@ static int
> vfio_iommu_type1_attach_group(void
> >>> *iommu_data,
> >>> INIT_LIST_HEAD(&domain->group_list);
> >>> list_add(&group->next, &domain->group_list);
> >>>
> >>> - if (!allow_unsafe_interrupts &&
> >>> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> >>> + msi_remap = resv_msi ? irq_domain_check_msi_remap() :
> >>
> >> There can be multiple interrupt-controller, at-least theoretically it is
> possible and not sure practically it exists and supported, where not all may
> support IRQ_REMAP. If that is the case be then should we check for IRQ-
> REMAP for that device-bus irq-domain?
> >>
> > I mentioned in the cover letter that the approach was defensive and
> > rough today. As soon as we detect an MSI controller in the platform
> > that has no support for MSI remapping we flag the assignment as
> > unsafe. I think this approach was agreed on the ML. Such rough
> > assessment was used in the past on x86.
> >
> > I am reluctant to add more complexity at that stage. This can be
> > improved latter I think when such platforms show up.
>
> I don't think this is worth it. If the system is so broken that the designer
> cannot make up their mind about device isolation, too bad.
> People will either disable the non-isolating MSI controller altogether, or force
> the unsafe flag.
Understand, just want to be sure that this is a known limitation. It will be good if we have some comment around this function.
Thanks
-Bharat
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists