[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v7][RFC][PATCH 01/13] xen: RMRR fix
On 2014/10/28 17:39, Razvan Cojocaru wrote: On 10/28/2014 11:34 AM, 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:5. Before we take real device assignment, any access to RMRR may issue ept_handle_violation because of p2m_access_n. Then we just call update_guest_eip() to return.I.e. ignore such accesses? Why?Yeah. This illegal access isn't allowed but its enough to ignore that without further protection or punishment. Or what procedure should be concerned here based on your opinion?If the access is illegal, inject a fault to the guest or kill it, unless youKill means we will crash domain? Seems its radical, isn't it? So I guess its better to inject a fault. But what kind of fault you prefer currently?#GP (but this being arbitrary is why simply killing the guest is another option to consider).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 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.Jan makes a very good point. If a guest, as you say, maliciously Yes, he pointed out something I don't consider but really need to concern. accesses any of the guest's pages, a dom0 application (working via the mem_access mechanism) might want to know about it (regardless of what the guest itself can and cannot do). :) So please, make sure that no such application will get confused by the changes. Thanks for your further comments. Tiejun Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |