Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Sohil Mehta <sohil.mehta@intel.com>]

On 2/12/2026 3:47 PM, Borislav Petkov wrote:
> On Thu, Feb 12, 2026 at 03:04:44PM -0800, Sohil Mehta wrote:
>> Can we just deprecate the "Flags" bits of /proc/cpuinfo at this point?
>>
>> No production software can be using this meaningfully.
> 
> Before you do, grep glibc sources.
> 

I meant freeze at whatever we have today but stop adding to it. As
described below, it has been buggy for *some* features for a long time.

>> We have always said that the *absence* of the feature doesn't mean anything.
>> The feature could be disabled or the kernel doesn't know about it.
>>
>> And now we've realized that the *presence* of the feature in /proc/cpuinfo
>> doesn't mean anything either.
> 
> How so? The presence means, the kernel has enabled it. See
> Documentation/arch/x86/cpuinfo.rst
> 

The commit message says:

"The features are also visible in /proc/cpuinfo even though they are not
enabled... Examples of such feature flags are lam, fred, sgx,
ibrs_enhanced, split_lock_detect, user_shstk, avx_vnni and enqcmd."

So, as of today, if one of these features shows up, a user can't be sure
whether the kernel has enabled it or not. Right?

My suggestion is that:
Instead of (or maybe along with) fixing this buggy interface, would it
be better to put this information in something like debugfs/sysfs? So,
at least new user software can start using that.