On Tue, 2024-05-07 at 07:21 -0700, Sean Christopherson wrote: > > Keeping X86_FEATURE_IBT set will result in "ibt" being reported in > /proc/cpuinfo, > i.e. will mislead userspace into thinking IBT is supported and fully enabled > by > the kernel. For a security feature, that's a pretty big issue. Since the beginning, if you don't configure kernel IBT in Kconfig but the HW supports it, "ibt" will appear in /proc/cpuinfo. It never was a reliable indicator of kernel IBT enforcement. It is just an indicator of if the IBT feature is usable. I think tying kernel IBT enforcement to the CPU feature is wrong. But if you disable the HW feature, it makes sense that the enforcement would be disabled. CET is something that requires a fair amount of SW enablement. SW needs to do things in special ways or things will go wrong. So whether IBT is in use and whether it is supported by the HW are useful to maintain as separate concepts. > > To fudge around that, we could add a synthetic feature flag to let the kernel > tell KVM whether or not it's safe to virtualize IBT, but I don't see what > value > that adds over KVM checking raw host CPUID. A synthetic feature flag for kernel IBT seems reasonable to me. It's what I suggested on that thread I linked earlier. But Peterz was advocating for a bool. How enforcement would be exposed, would just be dmesg I guess. Having a new feature flag still makes sense to me. Maybe he could be convinced.
