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?
