From: Arvind Sankar <nivedita@alum.mit.edu>
To: Borislav Petkov <bp@alien8.de>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] Use feature bit names in clearcpuid=
Date: Sun, 20 Sep 2020 12:16:28 -0400 [thread overview]
Message-ID: <20200920161628.GA3951950@rani.riverdale.lan> (raw)
In-Reply-To: <20200920154228.GB7473@zn.tnic>
On Sun, Sep 20, 2020 at 05:42:28PM +0200, Borislav Petkov wrote:
> Hi,
>
> so tglx hates this clearcpuid= interface where you have to give the
> X86_FEATURE array indices in order to disable a feature bit for testing.
> Below is a first attempt (lightly tested in a VM only) to accept the bit
> names from /proc/cpuinfo too.
>
> I say "too" because not all feature bits have names and we would still
> have to support the numbers. Yeah, yuck.
>
> An exemplary cmdline would then be something like:
>
> clearcpuid=de,440,smca,succory,bmi1,3dnow ("succory" is wrong on
> purpose).
>
> and it says:
>
> [ 0.000000] Clearing CPUID bits: de 13:24 smca bmi1 3dnow
>
> Also, I'm thinking we should taint the kernel when this option is used.
>
> Thoughts?
I like it. Allowing 13:24 as input would be icing on the cake :)
Small comments below.
> @@ -273,21 +273,45 @@ static void __init fpu__init_parse_early_param(void)
> return;
>
> pr_info("Clearing CPUID bits:");
> - do {
> - res = get_option(&argptr, &bit);
> - if (res == 0 || res == 3)
> - break;
> -
> - /* If the argument was too long, the last bit may be cut off */
> - if (res == 1 && arglen >= sizeof(arg))
> - break;
> -
> - if (bit >= 0 && bit < NCAPINTS * 32) {
> - pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
> - setup_clear_cpu_cap(bit);
> +
> + while (argptr) {
> + int i;
> +
> + opt = (strsep(&argptr, ","));
> + if (!opt)
> + continue;
The !opt check is unnecessary: strsep() returns NULL iff argptr is NULL
on entry. The parentheses around strsep() also look odd.
> +
> + if (!kstrtoint(opt, 10, &bit)) {
Could make bit unsigned and use kstrtouint().
> + if (bit >= 0 && bit < NCAPINTS * 32) {
> + if (!x86_cap_flag(bit))
> + pr_cont(" " X86_CAP_FMT_BARE, x86_cap_flag_bare(bit));
> + else
> + pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
> +
> + setup_clear_cpu_cap(bit);
> + taint++;
> + continue;
> + }
Could always continue if it was a number, even if it was invalid, since
that shouldn't match a name in any case?
> }
> - } while (res == 2);
> +
> +#ifdef CONFIG_X86_FEATURE_NAMES
> + for (i = 0; i < 32 * NCAPINTS; i++) {
> + if (!x86_cap_flags[i])
> + continue;
> +
> + if (strcmp(x86_cap_flags[i], opt))
> + continue;
> +
> + pr_cont(" %s", opt);
> + setup_clear_cpu_cap(i);
> + taint++;
We could break out of the loop here -- we can't have multiple bits with
the same name, right?
> + }
> +#endif
> + }
> pr_cont("\n");
> +
> + if (taint)
> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> }
>
> /*
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-09-20 16:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-20 15:42 [RFC PATCH] Use feature bit names in clearcpuid= Borislav Petkov
2020-09-20 16:16 ` Arvind Sankar [this message]
2020-09-20 17:29 ` Borislav Petkov
2020-09-20 18:35 ` Arvind Sankar
2020-09-20 18:59 ` Borislav Petkov
2020-09-22 8:03 ` Thomas Gleixner
2020-09-22 8:13 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200920161628.GA3951950@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox