[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 you

Kill 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


 


Rackspace

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