public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Piotr Dąbrowski" <ultr@ultr.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: new cmdline parameter disable_cpu_features= (microcode update?)
Date: Tue, 5 Jan 2016 12:38:17 +0100	[thread overview]
Message-ID: <20160105113817.GE3718@pd.tnic> (raw)
In-Reply-To: <CAEApFrhJzPkrP3jSiZUd4f-vqf89y6T7q9fRpDPsPumvByC+6g@mail.gmail.com>

On Tue, Jan 05, 2016 at 01:27:21AM +0100, Piotr Dąbrowski wrote:
> Is the microcode's header encrypted too?
> I thought there are two Processor Flags fields ('pf') available [1].
> Are they what I think they are?
> Is the header signed too, or only the actual microcode blob below the
> headers is?
> Sorry if I get it all wrong and there is no use for further discussion.

Yes, the microcode loader is completely wrong for what you're trying to
achieve. Just forget about it. :)

> Do you think there is any point in actually implementing the
> kernel-only disable_cpu_features= option upstream
> and then somehow convince the userland to respect flags reported by
> the kernel instead of those from the CPU?

I don't think there is any. Because you'd need to force *all* userspace
to not do CPUID but ask the kernel instead and that is a problem
because older kernels won't have the newer features enabled in, say
/proc/cpuinfo, and userspace would have to fallback to CPUID or older
tools won't have the code to check /proc/cpuinfo and would do CPUID
so...

This is going to be one helluva mess.

So I don't think we need to, or can, do anything here - the TSX f*ckup
was a nasty one and I'm not aware of any BIOS chicken bit with which
users can disable it. Which was a bad idea to not have it, in hindsight.
Otherwise there would *not* have been a microcode patch in the first
place. Which, for itself, was a pain to distribute and apply everywhere,
as you've seen.

And if we had a BIOS chicken bit, people would go into the BIOS, turn
TSX off, the CPUID bit would be clear too and userspace would've cleanly
fallen back to the old implementation and things would've worked
smoothly.

Now, if the kernel could control which CPUID bits are set and cleared,
then disable_cpu_features= would work. Unfortunately, this is not the
case. And this would require that all CPU features have corresponding
CPUID bits. Which is not the case either. :-\

Which brings me back to the BIOS chicken bits... :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

      reply	other threads:[~2016-01-05 11:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 22:55 new cmdline parameter disable_cpu_features= (microcode update?) Piotr Dąbrowski
2016-01-04 23:16 ` Borislav Petkov
2016-01-05  0:27   ` Piotr Dąbrowski
2016-01-05 11:38     ` Borislav Petkov [this message]

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=20160105113817.GE3718@pd.tnic \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ultr@ultr.pl \
    /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