[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 20/22] xen/arm: ITS: Map ITS translation space



On Tue, 18 Aug 2015 20:14:43 +0100
Julien Grall <julien.grall@xxxxxxxxxx> wrote:

> Hi,
> 
> On 27/07/2015 04:12, vijay.kilari@xxxxxxxxx wrote:
> > From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>
> >
> > ITS translation space contains GITS_TRANSLATOR register
> 
> s/GITS_TRANSLATOR/GITS_TRANSLATOR/

I assume you mean GITS_TRANSLATER? ;-)
> 
> > which is written by device to raise LPI. This space needs
> > to mapped to every domain address space for all physical
> > ITS available,so that device can access GITS_TRANSLATOR
> 
> Ditto
> 
> > register using SMMU.
> 
> Marc pointed me today that if the processor is writing into 
> GITS_TRANSLATER it may be able to deadlock the system.
> 
> Reading more closely the spec (8.1.3 IHI0069A), there is undefined 
> behavior when writing to this register with wrong access size.
> 
> Currently the page table are shared between the processor and the SMMU, 
> so that means that a domain will be able to deadlock the processor and 
> therefore the whole platform.

Indeed. A CPU should *never* be able to write to the GITS_TRANSLATER
register. What would be the meaning anyway? How would a DeviceID be
sampled? This is definitely UNPREDICTIBLE territory, and you want to
make sure a guest cannot directly write to the HW.

> So we should never expose GITS_TRANSLATER into the processor page table. 
> Which means unsharing some parts if not all of the page tables between 
> the processor and the SMMU.

Agreed. It looks to me like the CPU should only see the the virtual
ITS, and nothing else.

Thanks,

        M.
-- 
Jazz is not dead. It just smells funny.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.