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: Wed, 13 Mar 2024 14:11:59 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"hao.p.peng@...ux.intel.com" <hao.p.peng@...ux.intel.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Isaku Yamahata <isaku.yamahata@...el.com>
Subject: Re: [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when
 checking attributes

On Wed, Mar 13, 2024, Rick P Edgecombe wrote:
> 2. lpage_info doesn't need to keep track of unaligned heads and tails
> because the unaligned part can never be huge. lpage_info_slot() can
> skip checking the array based on the slot, GFN and page size which it
> already has. Allocating kvm_lpage_info's for those and then carefully
> making sure they are always disabled adds complexity (especially with
> KVM_LPAGE_MIXED_FLAG in the mix) and uses extra memory. Whether it's a
> tiny bit faster that a conditional in a helper, I don't know.

I wouldn't prioritize speed, I would prioritize overall complexity.  And my gut
reaction is that the overall complexity would go up because we'd need to make
multiple paths aware that lpage_info could be NULL.  There are other side effects
to making something conditionally valid too, e.g. in the unlikely scenario where
we mucked up the allocation, KVM would silently fall back to 4KiB mappings, versus
today KVM would explode (bad for production, but good for development).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ