[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/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:
5. Before we take real device assignment, any access to RMRR may
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).

In this case I think we just need to refer to native behavior. So I feel
GP may be a little bit reasonable.

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

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.


Xen-devel mailing list



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