Re: [PATCH 1/1] x86/pti: Fix kernel warnings for pti= and nopti cmdline options.

[Dave Hansen <dave.hansen@intel.com>]

On 8/11/23 16:27, Jo Van Bulck wrote:
> On 11.08.23 14:36, Jo Van Bulck wrote:>   static enum pti_mode {
>>       PTI_AUTO = 0,
>> +    PTI_FORCE_AUTO,
>>       PTI_FORCE_OFF,
>>       PTI_FORCE_ON
>>   } pti_mode;
> 
> I introduced a new PTI_FORCE_AUTO value here to make pti=auto override
> any mitigations=off parameter. However, I realize now that this may
> inadvertently affect other functions that test for pti_mode == PTI_AUTO
> (eg in pti_kernel_image_global_ok()).
> 
> Having 2 constants PTI_AUTO and PTI_FORCE_AUTO is arguably not very
> neat, so we should better get rid of this. I see several options:
> 
> - not have pti=auto override mitigations=off
> - have a global var to indicate pti= argument was passed
> - set pti_mode = PTI_AUTO in the pti_mode == PTI_FORCE_AUTO if branch
> 
> Not sure which option would best match kernel coding guidelines?

This sound like it's getting a bit out of hand and reaching far beyond
cleaning up some (mostly) harmless warnings.

I bet we have a billion command-line parameters that conflict with each
other.  mitigations=off and pti=auto is probably the least of our
worries.  Nobody in their right mind is going to say, oh, I *only* want
PTI, I don't care about any other mitigations.  That's nuts.

mitigations=off is the big hammer.  If you set that, you're basically
shouting from the rooftops, "moar speed!!"  You don't get security after
that.

pti=auto does *not* need to override mitigations=off.