Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Steven Price <steven.price@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"devel@acpica.org" <devel@acpica.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>
Subject: RE: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
Date: Mon, 14 Dec 2020 14:47:08 +0000
Message-ID: <3d0a3ae81241474f91748dde0cdd4d39@huawei.com> (raw)
In-Reply-To: <6dcf51b2-cad5-d377-a34c-4e64fd3acbb8@arm.com>



> -----Original Message-----
> From: Steven Price [mailto:steven.price@arm.com]
> Sent: 14 December 2020 13:43
> To: Robin Murphy <robin.murphy@arm.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> iommu@lists.linux-foundation.org; devel@acpica.org
> Cc: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com;
> joro@8bytes.org; wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; Sami.Mujawar@arm.com
> Subject: Re: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
> 
> On 14/12/2020 12:33, Robin Murphy wrote:
> > On 2020-12-14 10:55, Shameerali Kolothum Thodi wrote:
> >> Hi Steve,
> >>
> >>> -----Original Message-----
> >>> From: Steven Price [mailto:steven.price@arm.com]
> >>> Sent: 10 December 2020 10:26
> >>> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>;
> >>> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> >>> iommu@lists.linux-foundation.org; devel@acpica.org
> >>> Cc: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com;
> >>> joro@8bytes.org; robin.murphy@arm.com; wanghuiqiang
> >>> <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo)
> >>> <guohanjun@huawei.com>; Jonathan Cameron
> >>> <jonathan.cameron@huawei.com>; Sami.Mujawar@arm.com
> >>> Subject: Re: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
> >>>
> >>> On 19/11/2020 12:11, Shameer Kolothum wrote:
> >>>> RFC v1 --> v2:
> >>>>    - Added a generic interface for IOMMU drivers to retrieve all the
> >>>>      RMR info associated with a given IOMMU.
> >>>>    - SMMUv3 driver gets the RMR list during probe() and installs
> >>>>      bypass STEs for all the SIDs in the RMR list. This is to keep
> >>>>      the ongoing traffic alive(if any) during SMMUv3 reset. This is
> >>>>      based on the suggestions received for v1 to take care of the
> >>>>      EFI framebuffer use case. Only sanity tested for now.
> >>>
> >>> Hi Shameer,
> >>>
> >>> Sorry for not looking at this before.
> >>>
> >>> Do you have any plans to implement support in the SMMUv2 driver? The
> >>> platform I've been testing the EFI framebuffer support on has the
> >>> display controller behind SMMUv2, so as it stands this series doesn't
> >>> work. I did hack something up for SMMUv2 so I was able to test the first
> >>> 4 patches.
> >>
> >> Thanks for taking a look. Sure, I can look into adding the support for
> >> SMMUv2.
> 
> Great, thanks!
> 
> >>>
> >>>>    - During the probe/attach device, SMMUv3 driver reserves any
> >>>>      RMR region associated with the device such that there is a unity
> >>>>      mapping for them in SMMU.
> >>>
> >>> For the EFI framebuffer use case there is no device to attach so I
> >>> believe we are left with just the stream ID in bypass mode - which is
> >>> definitely an improvement (the display works!)
> >>
> >> Cool. That’s good to know.
> >>
> >>   but not actually a unity
> >>> mapping of the RMR range. I'm not sure whether it's worth fixing this or
> >>> not, but I just wanted to point out there's still a need for a driver
> >>> for the device before the bypass mode is replaced with the unity
> >>> mapping.
> >>
> >> I am not sure either. My idea was we will have bypass STE setup for
> >> all devices
> >> with RMR initially and when the corresponding driver takes over(if
> >> that happens)
> >> we will have the unity mapping setup properly for the RMR regions. And
> >> for cases
> >> like the above, it will remain in the bypass mode.
> >>
> >> Do you see any problem(security?) if the dev streams remain in bypass
> >> mode for
> >> this dev? Or is it possible to have a stub driver for this dev, so
> >> that we will have
> >> the probe/attach invoked and everything will fall in place?
> >
> > The downside is that if a driver never binds to that device, it remains
> > bypassed. If some other externally-controlled malicious device could
> > manage to spoof that device's requester ID, that could potentially be
> > exploited.
> >
> >> TBH, I haven't looked into creating a temp domain for these types of
> >> the devices
> >> and also not sure how we benefit from that compared to the STE bypass
> >> mode.
> >
> > That said, setting up temporary translation contexts that ensure any
> > access can *only* be to RMR regions until a driver takes over is an
> > awful lot more work. I'm inclined to be pragmatic here and say we should
> > get things working at all with the simple bypass STE/S2CR method, then
> > look at adding the higher-security effort on top.
> >
> > Right now systems that need this are either broken (but effectively
> > secure) or using default bypass with SMMUv2. People who prefer to
> > maintain security over functionality in the interim can maintain that
> > status quo by simply continuing to not describe any RMRs.
> 
> I agree with Robin, let's get this working with the bypass mode (until
> the device binds) like you've currently got. It's much better than what
> we have otherwise. Then once that is merged we can look at the temporary
> translation context or stub driver. The temporary translation context
> would be 'neatest', but I'm only aware of the EFI framebuffer use case
> and for that it might be possible to do something simpler - if indeed
> anything is needed at all. I'm not sure how much we need to be worried
> about malicious devices spoofing requester IDs.

Perfect. I will keep the STE bypass and respin the series once the update
to the IORT rev E is made public(hope that will happen soon). In the
meantime, appreciate any feedback on the rest of the patches in this series.

Thanks,
Shameer

  reply index

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 12:11 Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E Shameer Kolothum
2021-03-22 10:36   ` Shameerali Kolothum Thodi
2021-03-22 21:57     ` Kaneda, Erik
2021-03-23 15:53       ` Lorenzo Pieralisi
2021-03-23 18:51         ` Kaneda, Erik
2021-03-24  9:50           ` Lorenzo Pieralisi
2021-03-25  8:40     ` Jon Nettleton
2021-03-25 15:54       ` Shameerali Kolothum Thodi
2021-04-15  7:27   ` Auger Eric
2020-11-19 12:11 ` [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2021-04-15  9:39   ` Auger Eric
2021-04-15 10:30     ` Shameerali Kolothum Thodi
2020-11-19 12:11 ` [RFC PATCH v2 3/8] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 4/8] ACPI/IORT: Add RMR memory regions reservation helper Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 5/8] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 6/8] iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent() Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 7/8] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2020-11-19 12:11 ` [RFC PATCH v2 8/8] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev Shameer Kolothum
2020-12-10 10:25 ` [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node Steven Price
2020-12-14 10:55   ` Shameerali Kolothum Thodi
2020-12-14 12:33     ` Robin Murphy
2020-12-14 13:42       ` Steven Price
2020-12-14 14:47         ` Shameerali Kolothum Thodi [this message]
2020-12-17 14:47           ` Jon Nettleton
2020-12-17 15:42             ` Shameerali Kolothum Thodi
2020-12-17 15:53               ` Jon Nettleton
2020-12-18 10:53                 ` Jon Nettleton
2021-01-04  8:55                   ` Shameerali Kolothum Thodi
2021-01-04 10:55                     ` Jon Nettleton
2021-04-09  9:50 ` Auger Eric
2021-04-09 10:08   ` Shameerali Kolothum Thodi
2021-04-15  9:48 ` Auger Eric
2021-04-15 10:37   ` Shameerali Kolothum Thodi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d0a3ae81241474f91748dde0cdd4d39@huawei.com \
    --to=shameerali.kolothum.thodi@huawei.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=devel@acpica.org \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=wanghuiqiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git