Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS

[Borislav Petkov <bp@alien8.de>]

On Wed, Feb 22, 2023 at 09:16:21AM -0800, KP Singh wrote:
> Thanks for iterating. I think your commit description and rewrite
> omits a few key subtleties which I have tried to reinforce in both the
> commit log and the comments.
> 
> Q: What does STIBP have to do with IBRS?
> A: Setting the IBRS bit implicitly enables STIBP / some form of cross
> thread protection.

That belongs in the docs, if you want to explain this properly.

> Q: Why does it work with eIBRS?
> A: Because we set the IBRS bit once and leave it set when using eIBRS

Also docs.

> I think this subtlety should be reinforced in the commit description
> and code comments so that we don't get it wrong again. Your commit
> does answer this one (thanks!)

Commit messages are fine when explaining *why* a change is being done.
What is even finer is when you put a lenghtier explanation in our
documentation so that people can actually find it. Finding text in
commit messages is harder...

> Q: Why does it not work with the way the kernel currently implements
> legacy IBRS?
> A: Because the kernel clears the bit on returning to user space.

From the commit message:

    However, on return to userspace, the IBRS bit is cleared for performance
    reasons. That leaves userspace threads vulnerable to cross-thread
    predictions influence against which STIBP protects.

> The reason why I refactored this into a separate helper was to
> document the subtleties I mentioned above and anchor them to one place
> as the function is used in 2 places. But this is a maintainer's
> choice, so it's your call :)

The less code gets added in that thing, the better. Not yet another
helper pls.
 
> I do agree with Pawan that it's worth adding a pr_info about what the
> kernel is doing about STIBP.

STIBP status gets dumped through stibp_state().

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette