linux-kernel - Re: [PATCH v5 07/17] KVM: x86: add fields to struct kvm

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] [day] [month] [year] [list]

Date: Wed, 8 May 2024 15:04:12 +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>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Zhao, Yan Y" <yan.y.zhao@...el.com>,
	"michael.roth@....com" <michael.roth@....com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
Subject: Re: [PATCH v5 07/17] KVM: x86: add fields to struct kvm_arch for CoCo
 features

On Wed, 2024-05-08 at 07:38 -0700, Sean Christopherson wrote:
> > Ok, thanks for clarification. So it's more of a strategic thing to move more
> > zapping logic into userspace so the logic can change without introducing
> > kernel
> > regressions.
> 
> You're _really_ reading too much into my suggestion.  As above, my suggestion
> was very spur of the momemnt.  I haven't put much thought into the tradeoffs
> and
> side effects.

I'm not taking it as a mandate. Just trying to glean your insights. That said,
I'm really on the fence and so leaning on your intuition as the tie breaker.

For TDX's usage a struct kvm bool seems simpler code wise in KVM, and for
userspace. But the zapping logic as ABI problem seems like a reasonable thing to
think about while we are designing new ABI. Of course, it also means KVM has to
be responsible now for safely zapping memory from a variety of userspace
algorithms. So it somewhat makes KVM's job easier, and somewhat makes it harder.

The real issue might be that that problem was never debugged. While there is no
evidence it will affect TDXs, it remains a possibility. But we can't do the zap
roots thing for TDX, so in the end the ABI design will not affect TDX exposure
either way. But making it a normal feature will affect exposure for normal VMs.
So we are also balancing ABI flexibility with exposure to that specific bug.