Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Map mmio-sram nodes as cached memory

[Julien Grall <julien.grall@xxxxxxx>]

Hi Edgar,

On 16/12/2016 18:04, Edgar E. Iglesias wrote:
> On Fri, Dec 16, 2016 at 04:12:00PM +0000, Julien Grall wrote:
> > On 15/12/16 11:26, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>
> > >
> > > Relax the mapping of mmio-sram nodes that do not set the
> > > no-memory-wc property to cached normal memory.
> > >
> > > Rationale:
> > > Allthough on chip memories are relatively fast compared to
> > s/Allthough/Although/
> Fixed for v2.
>
> > > off-chip memories, large OCMs are still significantly slower
> > May I ask what does OCMs mean?
> It means On Chip Memories. I can spell it out in v2.
Yes please. I was not able to find the acronym with a quick search Google.

[...]

> > I consider it as the most trusted domain and has other way to mess up the
> > platform. So I am fine with this relaxation for the hardware domain (AKA
> > DOM0).
> >
> > However, I have the feeling that we need this kind of relaxation for many
> > devices. For instance prefetchable memory BARs for PCI would have to be
> > cacheable, same for integrated graphic cards.
> Yes, I agree.
>
> > I am wondering whether for DOM0 only (*not the other guests), we should
> > relax the default stage-2 attribute mapping to p2m_mmio_direct_c.
> >
> > So we would let DOM0 in charge of the final attribute. This may boost the
> > performance of memory access in DOM0.
> >
> > Any opinions?
> I think it makes sense. We had a discussiong about it a while back ago:
> https://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02349.html
>
> The concerns that were raised were wether there could be devices that
> could behave badly and possibly giving dom0 access to trig undefined or
> unpredictable behavior that could be exploited.
I think it would be fine for DOM0. It is already a trusted domain and 
have other way to take down the platform.
> If dom0 accesses devices through a cache, access patterns will change.
> In theory it may trig unexpected behaviour in some device. It's hard
> to say unless talking about specific chips and implementations.
>
> For example, given dom0 access to a DMA capable device may also achieve
> the same. I.e access patterns from DMA units differ from the ones
> originating from a CPU using uncached device memory. It could trig
> similar kind of errors.
Another example is having the device mapped with different in 2 places 
with different cacheability attributes. The data accessed would not be 
coherent. But I believe that should not lead to a security issue.
> It would be interesting to see a concrete example of a problematic
> system.
I believe it would depend a lot on how the platform have been designed.

I think we have two choices to go forward:
	1) Relax the memory attribute on case by case. DOM0 would not be able 
to exploit potential undefined behavior. However, this means that code 
is been added for any new device (e.g compatible string).
	2) Relax the memory attribute on every case. DOM0 would be able to 
exploit potential undefined behavior. On the benefit side, every devices 
can be used at its full performance without any change required in Xen.
In the case of ACPI, we rely on DOM0 to provide the correct mapping 
attribute when asking to do the stage-2 mapping (see 
XENMAPSPACE_dev_mmio). Note that currently, the MMIO are always mapped 
with the attribute Device-nGnRE. There is plan to change that in the 
future. So ACPI is implementing 2).
Device Tree is currently implementing 1). But I would like to see the 
behavior of Xen the same no matter the firmware tables used. So I would 
lean towards 2).
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel