linux-kernel - Re: [PATCH v4] kvm: Fix page ageing bugs

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: <542270BA.4090708@gmail.com>
Date:	Wed, 24 Sep 2014 15:20:26 +0800
From:	Wanpeng Li <kernellwp@...il.com>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	Wanpeng Li <wanpeng.li@...ux.intel.com>,
	Andres Lagar-Cavilla <andreslc@...gle.com>
CC:	Gleb Natapov <gleb@...nel.org>, Radim Krcmar <rkrcmar@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Peter Feiner <pfeiner@...gle.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4] kvm: Fix page ageing bugs

Hi Paolo,
于 9/24/14, 3:04 PM, Paolo Bonzini 写道:
> Il 24/09/2014 04:27, Wanpeng Li ha scritto:
>> Hi Andres,
>> On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>>> 1. We were calling clear_flush_young_notify in unmap_one, but we are
>>> within an mmu notifier invalidate range scope. The spte exists no more
>>> (due to range_start) and the accessed bit info has already been
>>> propagated (due to kvm_pfn_set_accessed). Simply call
>>> clear_flush_young.
>>>
>>> 2. We clear_flush_young on a primary MMU PMD, but this may be mapped
>>> as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
>>> This required expanding the interface of the clear_flush_young mmu
>>> notifier, so a lot of code has been trivially touched.
>>>
>>> 3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
>>> the access bit by blowing the spte. This requires proper synchronizing
>>> with MMU notifier consumers, like every other removal of spte's does.
>>>
>> [...]
>>> ---
>>> +	BUG_ON(!shadow_accessed_mask);
>>>
>>> 	for (sptep = rmap_get_first(*rmapp, &iter); sptep;
>>> 	     sptep = rmap_get_next(&iter)) {
>>> +		struct kvm_mmu_page *sp;
>>> +		gfn_t gfn;
>>> 		BUG_ON(!is_shadow_present_pte(*sptep));
>>> +		/* From spte to gfn. */
>>> +		sp = page_header(__pa(sptep));
>>> +		gfn = kvm_mmu_page_get_gfn(sp, sptep - sp->spt);
>>>
>>> 		if (*sptep & shadow_accessed_mask) {
>>> 			young = 1;
>>> 			clear_bit((ffs(shadow_accessed_mask) - 1),
>>> 				 (unsigned long *)sptep);
>>> 		}
>>> +		trace_kvm_age_page(gfn, slot, young);
>> IIUC, all the rmapps in this for loop are against the same gfn which
>> results in the above trace point dump the message duplicated.
> You're right; Andres's patch "[PATCH] kvm/x86/mmu: Pass gfn and level to
> rmapp callback" helps avoiding that.

 From Andres's patch "[PATCH] kvm/x86/mmu: Pass gfn and level to rmapp 
callback"

@@ -1410,25 +1421,20 @@ static int kvm_age_rmapp(struct kvm *kvm, 
unsigned long *rmapp,

for (sptep = rmap_get_first(*rmapp, &iter); sptep;
sptep = rmap_get_next(&iter)) {
- struct kvm_mmu_page *sp;
- gfn_t gfn;
BUG_ON(!is_shadow_present_pte(*sptep));
- /* From spte to gfn. */
- sp = page_header(__pa(sptep));
- gfn = kvm_mmu_page_get_gfn(sp, sptep - sp->spt);
-
if (*sptep & shadow_accessed_mask) {
young = 1;
clear_bit((ffs(shadow_accessed_mask) - 1),
(unsigned long *)sptep);
}
- trace_kvm_age_page(gfn, slot, young);
+ trace_kvm_age_page(gfn, level, slot, young);
}
return young;
}


This trace point still dup duplicated message for the same gfn in the 
for loop.

Regards,
Wanpeng Li

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

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