On Mon, 2024-05-06 at 16:33 -0700, Sean Christopherson wrote: > > Hmm, I don't disagree, but I'm not sure it makes sense to wait on that > discussion > to exempt IBT from the "it must be supported in the host" rule. I suspect > that > tweaking the handling X86_FEATURE_IBT of will open a much larger can of worms, > as overhauling feature flag handling is very much on the x86 maintainers todo > list. > > IMO, the odds of there being a hardware bug that necessitates hard disabling > IBT > are lower than the odds of KVM support for CET landing well before the feature > stuff is sorted out. I see a few reasons to tie to the host cpu feature: 1. Disabling it because of some HW concern. I agree with your assessment on the chances. 2. Having the cpu feature be disabled by some kernel parameter, and having KVM try to use it without the necessary FPU or other host support. It could cause lots of problems, guest->host DOS, etc. 3. Confusion for the user about which CPU features are actually in use on the system. There is a fair chance for compatibility issues to show up with CET. Today there is clearcpuid. If a user was having issues with CET and just wanted to turn it off, they might use clearcpuid or something else to just disable CET. Then boot a VM and find it was still enabled. For shadow stack there is also nousershstk. So, my two cents, it's just all easier to reason about for everyone if you tie it to host cpu features. I don't immediately see what trouble will be in giving kernel IBT a disable parameter that doesn't touch X86_FEATURE_IBT at some point in the future. Sorry if I'm missing the point. So like, ibt=off disables all IBT including kernel IBT, kernel_ibt=off disables kernel IBT enforcement via a global bool.
