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

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

  • To: Jan Beulich <JBeulich@xxxxxxxx>, Tiejun Chen <tiejun.chen@xxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 28 Oct 2014 11:39:40 +0200
  • Cc: yang.z.zhang@xxxxxxxxx, kevin.tian@xxxxxxxxx, tim@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 28 Oct 2014 09:39:47 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=jcHDXQ7n4PEY9PYpuWnLvGQABjk8XoFWd7HY6GsNrWzz6b6gsL48/3sAgZBY0Gqt3GOLwb8t8NuBWV/WcbetG4HBoRwXzPiAtgjMRbxkTuNq25Ceydx10fhQa0DaNwrNJV9BLbkOIsG1gJCe1x1PERQhF+H07P+I/QidECCOXN1gpr3s0fBYhbLGOikTK8vDAaqC49gPRqje3gNShXvyDBOfvbiYh8+O0v6uX6EJ52SSOn96XD8Wg88viBnG0tgrR4ANnf2m3K0eR02JwzqXNLOhUMJxBARIPIzZhEvxtkcm89zlzaJSxypH1y4aEhvqr9JyRLqLwvOiISdB/a5Wkg==; h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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


Xen-devel mailing list



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