linux-kernel - Re: [PATCH 1/1] x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 3 Nov 2020 11:57:57 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Anand K. Mistry" <amistry@...gle.com>
Cc:     Tom Lendacky <thomas.lendacky@....com>, x86@...nel.org,
        Joel Fernandes <joelaf@...gle.com>,
        Anthony Steinhauser <asteinhauser@...gle.com>,
        tglx@...utronix.de, "H. Peter Anvin" <hpa@...or.com>,
        Ingo Molnar <mingo@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Mike Rapoport <rppt@...nel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        Vineela Tummalapalli <vineela.tummalapalli@...el.com>,
        Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] x86/speculation: Allow IBPB to be conditionally
 enabled on CPUs with always-on STIBP

On Mon, Nov 02, 2020 at 11:02:10AM +1100, Anand K. Mistry wrote:
> > I like the idea of passing in the mode you want to check, but it appears
> > they are never used independently. The ibpb and stibp modes are always
> > checked together in one of the if statements below, so you could make this
> > a function that checks both modes and just have a single call. I'll leave
> > that up to the maintainers to see what is preferred.
> 
> I can see both sides to this. Personally, I think I prefer it as-is
> since I think it improves readability a bit by making the conditions
> less complicated whilst not hiding too many details. I'll wait to see
> what others say before changing this one.

Yes, but if you make it a single function with a descriptive name, you'd
make the call sites even more readable:

	if (!is_spec_ib_conditional(..))
		bla;

or

	if (!is_spec_ib_user_controlled(..))
		blu;

and that function should simply check both spectre_v2_user_ibpb *and*
spectre_v2_user_stibp in one go.

Why should we do that?

Exactly because you both got your brains twisted just from looking at
this. Because this mitigation crap is such an ugly and complex maze that
we would take even the smallest simplification any day of the week!

Welcome to my life since meltdown. Brain twist feels good, doesn't it?

:-)))

Thx.

-- 
Regards/Gruss,
    Boris.

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