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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

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

> 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?

> 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.

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