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]
Date: Tue, 25 Jun 2024 20:33:20 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>, "sagis@...gle.com"
	<sagis@...gle.com>, "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
	"Aktas, Erdem" <erdemaktas@...gle.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "dmatlack@...gle.com" <dmatlack@...gle.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 13/17] KVM: x86/tdp_mmu: Support mirror root for TDP
 MMU

On Tue, 2024-06-25 at 13:43 +0800, Yan Zhao wrote:
> > > > I was originally suspicious of the asymmetry of the tear down of mirror
> > > > and
> > > > direct roots vs the allocation. Do you see a concrete problem, or just
> > > > advocating for safety?
> > IMO it's a concrete problem, though rare up to now. e.g.
> > 
> > After repeatedly hot-plugping and hot-unplugping memory, which increases
> > memslots generation, kvm_mmu_zap_all_fast() will be called to invalidate >
> > direct
> > roots when the memslots generation wraps around.

Hmm, yes. I'm not sure about putting the check there though. It adds even more
confusion to the lifecycle.
 - mirror_root_hpa != INVALID_PAGE check in a different placed than
   root.hpa != INVALID_PAGE check.
 - they get allocated in the same place
 - they are torn down in the different places.

Can you think of clearer fix for it. Maybe we can just move the mirror root
allocation such that it's not subjected to the reload path? Like something that
matches the tear down in kvm_mmu_destroy()?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ