[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |