linux-kernel - Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

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]

Message-ID: <20180127093722.t6dn4sgocihjjq37@pd.tnic>
Date:   Sat, 27 Jan 2018 10:37:22 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Tom Lendacky <thomas.lendacky@....com>, x86-ml <x86@...nel.org>,
        linux-tip-commits@...r.kernel.org, hpa@...or.com,
        gregkh@...uxfoundation.org, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, mingo@...nel.org
Subject: Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Sat, Jan 27, 2018 at 09:27:48AM +0000, David Woodhouse wrote:
> http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
> tree?

@@ -223,7 +223,7 @@ static inline void indirect_branch_prediction_barrier(void)
 				 "movl %[val], %%eax\n\t"
 				 "movl $0, %%edx\n\t"
 				 "wrmsr",
-				 X86_FEATURE_IBPB)
+				 X86_FEATURE_USE_IBPB)

I still don't think that's the right approach: I'd call the
software-defined, synthetic features

X86_FEATURE_IBPB
X86_FEATURE_IBRS
X86_FEATURE_STIBP

then make *them* visible in /proc/cpuinfo and use them everywhere in the
code.

Only the vendor-specific detection code will set the synthetic ones when
it detects a corresponding vendor-specific one.

This way one *only* concentrates on the three above everywhere and
only low-level, early, vendor-specific code takes care to set the
corresponding synthetic features based on the actual hardware bits it
detects.

I think that unifies the view both to the user *and* to the rest of the
kernel which should not care about the actual name of a hardware feature
bit.

And then you avoid coders scratching heads, asking, so what should I
use, X86_FEATURE_IBPB or X86_FEATURE_USE_IBPB.

Instead you call IBPB the synthetic one and the hardware feature name is
something different like PRED_CMD or so. This will drop the confusion
additionally.

I hope that makes sense.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.