linux-kernel - Re: [PATCH] KVM: x86/mmu: x86: Don't overflow lpage

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 21:23:02 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.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>, "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when
 checking attributes

On Wed, 2024-03-13 at 14:11 -0700, Sean Christopherson wrote:
> 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).

Fair enough, I won't hurry up and try. I'm not sure there would be too
many places that would have to handle the out-of-bounds case once
everything was suitable wrapped up, though.