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, 22 May 2024 15:06:47 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Yang, Weijiang" <weijiang.yang@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"x86@...nel.org" <x86@...nel.org>, "peterz@...radead.org"
	<peterz@...radead.org>, "john.allen@....com" <john.allen@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"mlevitsk@...hat.com" <mlevitsk@...hat.com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace

On Wed, 2024-05-22 at 17:03 +0800, Yang, Weijiang wrote:
> Side topic:  would it be reasonable to enforce IBT dependency on
> XFEATURE_CET_USER when *user* IBT
> enabling patches are landing in kernel? Then guest kernel can play with user
> IBT alone if VMM
> userspace just wants to enable IBT for guest. Or when SHSTK is disabled for
> whatever reason.

I think earlier there was a comment that CET would be less likely to need to be
disabled for security reasons, so there would not be utility for a system wide
disable (that affects KVM). I recently remembered we actually already had a
reason come up.

The EDK2 SMI handler uses shadow stack and had a bug around saving and restoring
CET state. Using IBT in the kernel was causing systems to hang. The temporary
fix was to disable IBT.

So the point is, let's not try to find a narrow way to get away with enabling as
much as technically possible in KVM.

The simple obviously correct solution would be:
XFEATURE_CET_USER + XFEATURE_CET_KERNEL + X86_FEATURE_IBT = KVM IBT support
XFEATURE_CET_USER + XFEATURE_CET_KERNEL + X86_FEATURE_SHSTK = KVM SHSTK support

It should be correct both with and without that patch to enable
XFEATURE_CET_USER for X86_FEATURE_IBT.

Then the two missing changes to expand support would be:
1. Fixing that ibt=off disables X86_FEATURE_IBT. The fix is to move to bool as
peterz suggested.
2. Making XFEATURE_CET_USER also depend on X86_FEATURE_IBT (the patch in this
series)

We should do those, but in a later small series. Does it seem reasonable? Can we
just do the simple obvious solution above for now?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ