From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>,
Matthew Whitehead <tedheadster@gmail.com>,
Brian Gerst <brgerst@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>
Subject: Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing
Date: Sun, 20 Nov 2016 17:34:43 -0200 [thread overview]
Message-ID: <20161120193442.GA1145@khazad-dum.debian.net> (raw)
In-Reply-To: <20161120173244.a2odm3rupohvatiq@pd.tnic>
On Sun, 20 Nov 2016, Borislav Petkov wrote:
> We will have set (or not) the X86_FEATURE_CPUID bit at
> early_identify_cpu() time. Looking at the code, we do call sync_core()
> pretty early. :-\
Hmm, watch out for the early microcode update driver for Intel
processors should something get changed in the implementation, or in the
behavior of sync_core().
That driver absolutely needs to issue a cpuid (with EAX = 1) before each
rdmsr(MSR_IA32_UCODE_REV). And it uses sync_core() calls to do it. A
CR2 access just won't do in this extremely specific case.
This kind of pitfall is why I wanted to replace all use of sync_core()
in arch/x86/kernel/cpu/microcode/intel.c with an explicit use of an
inconditional cpuid(eax = 1)...
(note: this protocol to read MSR_IA32_UCODE_REV was made an
architectural requirement a while ago -- it was once considered an
erratum workaround. It is documented in the "Intel 64 and IA‐32
Architectures Software Developer's Manual", Volume 3A: System
Programming Guide, Part 1, section 9.11).
--
Henrique Holschuh
next prev parent reply other threads:[~2016-11-20 19:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-19 23:37 [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing Andy Lutomirski
2016-11-20 11:19 ` Borislav Petkov
2016-11-20 16:22 ` Andy Lutomirski
2016-11-20 17:32 ` Borislav Petkov
2016-11-20 19:34 ` Henrique de Moraes Holschuh [this message]
2016-11-20 20:47 ` Borislav Petkov
2016-11-21 8:48 ` [tip:x86/urgent] " tip-bot for Andy Lutomirski
2016-11-30 13:18 ` [PATCH] " One Thousand Gnomes
2016-11-30 18:28 ` Andy Lutomirski
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=20161120193442.GA1145@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=tedheadster@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.