Re: xen/arm: On chip memory mappings

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

On Tue, May 19, 2015 at 10:23:05AM +0100, Julien Grall wrote:
> 
> 
> On 19/05/2015 10:09, Ian Campbell wrote:
> >On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote:
> >>Hi,
> 
> Hi,
> 
> >>The rules for combining the memory attributes from S1 and S2 translations
> >>suggest that mapping things at S2 with Normal memory Inner/Outer WB cacheable
> >>would give the guest/S1 flexibility in choosing the final attributes.
> >>It seems to me like guest drivers have the best knowledge to decide how to
> >>map the node memory regions.
> >>
> >>Keeping the S2 shareability set to inner (like we already do for memory)
> >>seems to be a good idea though.
> >>
> >>So the question I had is, why do we map nodes at S2 with DEVICE attributes at all?
> >>Am I missing something?
> >
> >I think the concern was exposing potentially UNPREDICTABLE /
> >IMPLEMENTATION DEFINED etc behaviour via a guest which maps MMIO regions
> >as normal memory in S1. By using a device memory mapping in S2 we force
> >a safe overall result.
> >
> >I've not refreshed my memory on the way round this goes though, perhaps
> >the worry is/was unfounded. In particular perhaps on v8 this ends up as
> >CONSTRAINED UNPREDICTABLE which might be safe enough (again, I've not
> >checked).
> >
> >I'd rather not have v7 and v8 differ in such a fundamental default, but
> >it might be justified I suppose. Likewise for e.g. doing something
> >different for dom0/hw-dom vs. others.
> 
> I remember a similar discussion with Christoffer few months ago (it
> was for ACPI). And the answer was:
> 
> "No, real access to MMIO regions of devices must be mapped as device
> type in stage-2 if you don't want potential information leaks or weird
> things to happen where a guest can tweak and time memory operations
> such that they happen in a different context than the VM executing the
> memory access.
> 
> You can argue that the latter is not necessary for Dom0 as Xen trusts
> Dom0 completely, but I would still argue that it is the right approach
> to take proper care of it, thus;"
> 
> Regards,


Thanks for the pointers,

I agree that fundamental differences like these beteween v7 and v8 wouldn't
be good.

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.

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.

I'm not sure I understand Christoffers arguments though.

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.

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

Anyway, at the moment it seems like doing a device-tree compatiblity prop
match for mmio-sram would be the path with least resistance...

Cheers,
Edgar