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

Re: [Xen-devel] [v7][RFC][PATCH 01/13] xen: RMRR fix

>>> On 29.10.14 at 03:51, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/10/29 8:48, Chen, Tiejun wrote:
>> On 2014/10/28 17:34, Jan Beulich wrote:
>>>>>> On 28.10.14 at 09:36, <tiejun.chen@xxxxxxxxx> wrote:
>>>> On 2014/10/27 17:41, Jan Beulich wrote:
>>>>>>>> On 27.10.14 at 03:00, <tiejun.chen@xxxxxxxxx> wrote:
>>>>>> n 2014/10/24 18:52, Jan Beulich wrote:
>>>>>>>>>> On 24.10.14 at 09:34, <tiejun.chen@xxxxxxxxx> wrote:
>>>>>>>> Now in our case we add a rule:
>>>>>>>>     - if p2m_access_n is set we also set this mapping.
>>>>>>> Does that not conflict with eventual use mem-access makes of this
>>>>>>> type?
>>>> Do you mean what will happen after we reset these ranges as
>>>> p2m_access_rw? We already reserve these ranges guest shouldn't access
>>>> these range actually. And a guest still maliciously access them, that
>>>> device may not work well.
>>> mem-access is functionality used by a control domain, not the domain
>> I really don't know this mechanism so thanks for your good coverage.
>>> itself. You need to make sure that neither your use of p2m_access_n
>>> can confuse the mem-access code, nor that their use can confuse you.
>> Absolutely, but I think I need to know more about mem-access firstly.
> I think these reserved device memory shouldn't be pocked since any write 
> may affect device. Even, what if a device with RMRR isn't assign current 
> domain? And read also should not be allowed since this still may 
> introduce some potential unexpected behavior to device.
> So if mem_access is trying to access those RMRR range, could we let 
> mem_access exit directly with some message? I mean we can check if we're 
> accessing those RMRR ranges in case of XENMEM_access_op_set_access.

Sounds reasonable at first glance.


Xen-devel mailing list



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