Re: [Xen-devel] xen/arm: On chip memory mappings

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

On Wed, May 20, 2015 at 03:12:24PM +0100, Julien Grall wrote:
> On 20/05/15 14:40, Edgar E. Iglesias wrote:
> > Thanks for the pointers,
> > 
> > I agree that fundamental differences like these beteween v7 and v8 wouldn't
> > be good.
> 
> I didn't find any fundamental differences for device memory behavior in
> the spec.
> 
> > Possible unpredictable behaviour is worrysome...
> > I'm not aware of anything in the ARM architecture specs that would
> > cause it in this respect, but I may be missing something.
> 
> AFAICT there is nothing in the spec which describe the behavior of a
> region access with wrong memory attribute (i.e normal, device, strong).
> 
> I guess this would be described in the memory bus or processor spec.
> 
> > There might also very well be device/slave specific unpredictability. 
> > E.g unpredictable behaviour on specific AXI access patterns
> > (bursts, sizes etc) to specific devices...
> > On the other hand, I suppose giving direct device access to a guest
> > carries some kind of trust to behave nicely with the device.
> 
> The trust to the device is very limited. We got several Xen Security
> Advisory ([1] [2] ...) related to PCI passthrough.
> 
> I agree that the guest may act badly with the device, although we don't
> want to give him the opportunity to act more badly with a device and the
> possibility to access another guest memory.
> 
> > I'm not sure I understand Christoffers arguments though.
> 
> It's not clear what is the behavior of a device memory mapped with
> normal attribute. Many issue can appear.

I think this is very device-specific.

For example, if SW is writing to a FIFO register but accesses are
getting buffered and combined, data-loss may happen (the cache consumes
multiple repeated stores into one single final store). That is pretty
harmless but for example if a slave is buggy or not protocol complete,
maybe not supporting specific AXI burst patterns and we allow guests to
(via caches) send such transactions to those slaves, things could go bad
in terms of locking up the device or maybe even the CPU. But not in terms
of getting access to other guests memory, AFAICT.

It sounds to me like this is more a question of trust model, i.e how
much do we "trust" guests with direct-device access.

Sounds like we should stick with the current mapping approach to play it
safe.


> Unless the behavior is clearly written in the spec, we should take the
> worst case and not the best.

Agreed.

> 
> > A well behaved guest will map it's devices as DEVICE and there
> > won't be any difference at all wether S2 maps them as dev or mem.
> 
> Agree.
> 
> > A malicious guest could map things as cached memory and try to cause
> > cached accesses from other guests to flush out. But these cached accesses
> > would only contain data for other guests mapped as cacheable memory. AFAICT,
> > to really hurt another guest, the guest under attack has to participate
> > in the plot (by incorrectly mapping it's own devs as mem).
> 
> Why not RAM?

Because RAM is already OK to map as Normal cached memory. I.e, there are no
side-effects, prefetching is OK, buffering and combining is OK. The malicious
guest cannot reach cached memory for another guest because the MMUs/SMMUs will
shoot down those accesses.

If the well-behaved guest for some reason needs to map memory with less caching,
it can do so by setting the right attributes in the S1 tables (i.e more 
restricted
access trumps over the relaxed S2 attributes).


> 
> > Anyway, at the moment it seems like doing a device-tree compatiblity prop
> > match for mmio-sram would be the path with least resistance...
> 
> I think this is a good solution until we figure out the behavior of
> device memory mapped with wrong attribute.

Thanks.

Best regards,
Edgar


> 
> Regards,
> 
> [1] http://xenbits.xen.org/xsa/advisory-124.html
> [2] http://xenbits.xen.org/xsa/advisory-126.html
> 
> -- 
> Julien Grall

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