linux-kernel - Re: [PATCH v6 5/9] KVM: MMU: introduce SPTE_MMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FD804D7.5000802@linux.vnet.ibm.com>
Date:	Wed, 13 Jun 2012 11:11:19 +0800
From:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
CC:	Avi Kivity <avi@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
	KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH v6 5/9] KVM: MMU: introduce SPTE_MMU_WRITEABLE bit

On 06/13/2012 10:01 AM, Marcelo Tosatti wrote:

> On Tue, Jun 12, 2012 at 10:23:47AM +0800, Xiao Guangrong wrote:
>> On 06/12/2012 07:32 AM, Marcelo Tosatti wrote:
>>
>>> On Tue, May 29, 2012 at 02:49:14PM +0800, Xiao Guangrong wrote:
>>>> This bit indicates whether the spte can be writable on MMU, that means
>>>> the corresponding gpte is writable and the corresponding gfn is not
>>>> protected by shadow page protection
>>>
>>> Why is this still necessary, now that only sptes of direct shadow pages 
>>> are updated locklessly? 
>>>
>>
>>
>> Yes, but it is still needed, for nested npt/ept, we need protect
>> the nested page tables.
> 
> Sure, but shadowed L1 nested pagetables are not direct shadow pages.
> 
> They are shadows of L1 nested pagetables. 
> 
> Checking sp->direct should be enough (instead of the flags).
> 

Hi Marcelo,

I think it is not enough, for example:

- In host (L0), spte1 is pointing to gfn1, spte1 is a direct spte.

- in L1, L1 guest is using gfn1 in L1's ept page table for L2 guest,
  so, in host, we have a indirect spte (named spte2) whose sp->gfn = gfn1.

Since spte2 is a indirect spte, we need protect it, so, we walk all gfn1's
rmaps, spte1 will be found, then, we write-protect on spte1 to track L1
modifying gfn1.

In this case, spte1 is direct but need write-protect. :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/