Brian Gregory wrote:
On 21/01/2018 15:15, Brian Gregory wrote:
On 21/01/2018 09:58, Yousuf Khan wrote:
On 1/21/2018 1:57 AM, Paul wrote:
Yousuf Khan wrote:
Seems to be much easier than trying to install and run PowerShell
scripts, and much more reliable too:
https://www.grc.com/inspectre.htm
Have you decided what's it doing ?
What is it actually reading out ?
Paul
The FAQ on that page mentions that since Meltdown doesn't affect AMD
systems, there is no patch needed to fix it on those systems. So you
can't enable or disable the fixes to test it, since the problem
simply doesn't exist on AMD. On Intel, if you don't have the latest
patches to fix Meltdown, then you also can't enable or disable the
fix, since the fix hasn't been applied.
For Spectre, it says that that requires a firmware upgrade. My
processor (AMD) shows that it's invulnerable to Meltdown, but
susceptible to Spectre. The way to fix Spectre requires a BIOS
upgrade. I have a feeling that I will never see another BIOS upgrade
for my system, as the last BIOS update for my board was 2013! The
board makers may update boards that are a year or two old, but not
this one.
Yousuf Khan
It seems to be possible to update the microcode from the OS and
Microsoft could do that if they wanted. Linux can do it.
I'm currently trying to investigate whether a Windows driver can
update it satisfactorily after discovering:
https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver
http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/
http://forum.notebookreview.com/threads/ucode-fix-for-spectre-ht-bug-fix-and-meltdown.806451/
I tried it by
1) extracting the contents of
CPU-microcode_06A14BA0506D12B69ED78E226F22CE0F9EEA6E1A .zip to a
directory.
2) running install.bat using "Run as Administrator".
3) Changing the registry with:
=============FIX1.REG STARTS===============
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servic es\cpumcupdate]
"Start"=dword:00000001
=============FIX1.REG ENDS================
Something definitely happens because, after rebooting, InSpectre
(Release 5) says "Vulnerable to Spect NO".
However something odd is going on and I'm not sure if it's because
Windows is patching the Microcode after it's decided what the
microcode patch level is, or maybe InSpectre (Release 5) has a bug.
The oddness is that Inspectre always starts with a button showing
"Enable Spectre Protection". This implies to me that this protection
is disabled. However pressing the button once leaves it as "Enable
Spectre Protection" but subsequent presses to toggle between "Disable
Spectre Protection" and "Enable Spectre Protection".
So maybe Inspectre (Release 5) just always starts showing "Enable
Spectre Protection" even if it is already correctly enabled.
I should add that my processor is Intel. If you do exactly the steps I
outlined it probably won't help with AMD since the AMD files in the
download I used seem to be very old.
But if you can find the AMD microcode files with the Spectre fix(es) in
them you're all set with AMD too. The latest I could find were December
2017, maybe AMD haven't finished testing yet.
If you're taking that course of action, you should have
installed Intel PIU first. Since microcode is volatile,
you can easily reboot and try the experiment again.
The revision field in the PIU window will show
you've managed to change the "revision" of the CPU.
When you turn on the power in the morning, the CPU
revision is 00. The BIOS has a microcode patch, which
is "good enough to boot with". If you run the bootable
Intel PIU on floppy (suitable for Linux users in a sense),
it might show 07 as the CPU revision. That means the BIOS
was successful installing microcode (patch to CPU instruction
set). If you get 00 from this, don't panic - it means
you've installed a CPU which is "not supported" by
your BIOS. This has happened before...
(Bootable floppy, for checking what the BIOS injected)
https://downloadcenter.intel.com/download/7840
When either Linux or Windows boots, they have a microcode
loader. What I learned this time around, is Linux has an
"early" and a "late" microcode loader. The distinction
isn't important for the discussion of this subject.
Microcode is accepted by the CPU if the family code matches,
the file is signed, the file is encrypted, and finally, a
check is done on the "revision" field. If the OS microcode
is 42, then 42 07, and the CPU accepts the microcode.
If you're running a virtual machine, the logic there is
simply horrible. The virtual environment, "fakes" the info
that PIU would get. Maybe your Win10 in a VM says it's running
17, when in fact, it isn't. A VM is not allowed to change
host state. It would have made more sense, if the value
returned was 42, as the CPU state is at 42 as viewed
on the Host, the CPU behavior is at 42, and any patches
running on the Guest, their logic "sniffs" the revision to
decide what to do. Don't be surprised if your Guest does
something dumb.
*******
I don't see a reason why *anything* cannot run microcode
updates, as long as it burrows into Ring0 or uses a
Ring0 service to do it. And as long as the patch is
vetted, and has a higher revision, it should be
accepted. You're not supposed to be able to write hardware
from Ring3 directly, and something has to do it on
your behalf. We call those "drivers" for lack of
a better word. It could also be a Kernel call,
as the Kernel lives in Ring0.
The OS has to decide when to "sniff" the revision, and
"arm" any patches. The OS (patch) code probably isn't
prepared for home experiments. Like, if the CPU
behavior is slightly different with that microcode
in place, the kernel behavior should change in
response.
Since microcode is volatile, and the entire loading
sequence into CPU writeable control store starts
from empty after every RESET, it's not like these
experiments are "permanent". By rebooting, you wipe
out your little adventure. If the machine hangs,
just press the RESET button and no harm done.
Microcode is only permanent, if you use one of
the existing delivery methods and change the file
it's using.
Microsoft is *always* shipping Microcode. At the moment,
it's delivering what I would guess to be Nov 2017 or
so microcode. Not Jan 8, 2018 microcode. Linux has
already delivered Jan 8, 2018 microcode. The microcode
file, while called "Linux" on the Intel site, is actually
suitable for *any* OS. Since Intel delivers a copy to
Microsoft directly, no web site delivery is needed. But
for the 500 distros out there, Intel provides microcode
for download, so those people can pick it up.
In the following release note, this shows, out of all the
CPUs in the microcode master file, which ones were changed
on January 8. Mine is probably the oldest CPU on the
list (fall 2013). Only one of my CPUs is patchable, for a
generic kind of Spectre protection. My P4s will *never* receive
a patch using this method (and they will need a bunch of
individual pieces of software to be patched instead).
This patch takes advantage of some modern arch features.
I barely made the cut. So one CPU out of the pile of CPUs
in my house, is covered this way. Just one.
Intel Processor Microcode Package for Linux 20180108 Release
-- Updates upon 20171117 release -- === delta, since this date
IVT C0 (06-3e-04:ed) 428-42a === my Q3'13 processor
SKL-U/Y D0 (06-4e-03:c0) ba-c2
BDW-U/Y E/F (06-3d-04:c0) 25-28
HSW-ULT Cx/Dx (06-45-01:72) 20-21
Crystalwell Cx (06-46-01:32) 17-18
BDW-H E/G (06-47-01:22) 17-1b
HSX-EX E0 (06-3f-04:80) 0f-10
SKL-H/S R0 (06-5e-03:36) ba-c2
HSW Cx/Dx (06-3c-03:32) 22-23
HSX C0 (06-3f-02:6f) 3a-3b
BDX-DE V0/V1 (06-56-02:10) 0f-14
BDX-DE V2 (06-56-03:10) 700000d-7000011
KBL-U/Y H0 (06-8e-09:c0) 62-80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70-80
KBL-H/S B0 (06-9e-09:2a) 5e-80
CFL U0 (06-9e-0a:22) 70-80
CFL B0 (06-9e-0b:02) 72-80
SKX H0 (06-55-04:b7) 2000035-200003c
GLK B0 (06-7a-01:01) 1e-22
My CPU is Ivy Bridge E, but the code 63e 04 and the
"Revision" field of 428 changing to 42a, all happened
on Linux, under Ubuntu. I only ran Linux,
so I could test Guest behavior in Virtualbox, and
the result inside there was shocking and silly at
the same time.
Windows leaves that machine at 428.
An earlier Linux DVD, booted live, left /proc/cpuinfo
information at 416. That tells me that the 428 Microsoft
has been delivering, up until the January patch, is "modern".
Microsoft has not been completely negligent on the microcode
front. Far from it. But, they're "gating" delivery right
now, probably waiting for Intel to resolve the Lenovo-detected
issues.
You can get PIU from Intel here. Select the language version
you desire. I'm using the English one.
https://downloadcenter.intel.com/dow...indows-Version
pidenu47.msi
There have been several versions of that utility over the
years. An "old" one for older CPUs. A "newer" one that may
correspond to that download. There is also a FreeDOS style
floppy version, which is particularly painful for a Linux
user to access, as they'd likely need a Windows machine
to cut a floppy for themselves. I tried to make a floppy
in a Linux VM, just to test out the "pain level" and it
didn't work in there. So the FreeDOS version for boot
from floppy (which shows your *BIOS* patch level), that's
easier to do on an actual Windows.
I look forward to your experimental results.
You can also run that inside your VirtualBox Guest in Windows
and discover that the revision is neither 428 nor 42a for
your Ivy Bridge E, and something else entirely. Indicating
the treatment is a shambles. I've yet to find a technical
article explaining how what the VM people have done is
"a good idea". There must be an article somewhere explaining it.
Linux booted in a VM, has "paravirtualization detection". It
*knows* it's in a VM. About ten years ago, I could find a
bugtracker entry, during PV detection development, where
someone said "you know, we really shouldn't be loading
microcode while we're running in a Guest", so they turn
off that behavior inside a VM. It does appear that OSes
are clueful - what's wrong is, the hosting software
is telling a lie about "Revision", which could foul up
the enablement of a proper response to whatever change
the microcode is making.
In fact, OSes contain a *lot* of patches for CPU quirks.
We just aren't aware of them. What happened in January
is *not* novel. It's *normal*. Every CPU has 100 bugs
in it, maybe 20-30% need minor changes in things like
the kernel. If you read the errata for your CPU,
you will see in the description text, some hint
or suggestion that an OS company needs to respond.
On Linux, 500 distros don't do this - only kernel.org
need be informed and interested. On Windows, only
Microsoft needs to take this into account. Work should
be going on behind the scenes *constantly* with regard
to CPU bugs.
The only CPU bugs we hear about are the *big* ones.
Not the *small* ones.
No CPU has ever been made with zero bugs. Not a one.
And at some point, the errata sheet seems to stop
growing, which to my mind is a bit suspicious.
Certainly testing stops on newly released CPUs
after a couple years. But the constancy of the size
of the errata sheet is just a bit strange. There might
only be a 2:1 ratio, between the bugginess of the
worst versus the best. The spread should be a lot
larger, implying fiddling of some sort.
*******
This picture from Intel isn't very clear. But this
is the CPUID tab of Intel PIU. The revision field
at the bottom is "60C". The leading 6, as far as
I'm concerned, is bogus. The "0C" implies 12 revisions
of microcode have been released. The number is in
hex, and "C" is equal to 12. When the various
microcode loaders do their thing, the highest
revision of microcode they attempt to load, "wins".
Intel tries to put the most bug-free microcode,
in the highest revision number microcode. The
holding back by Microsoft, of my 42a, indicates
that the microcode may not be fully baked, or
the response to the changes not finished yet.
And that's why Windows Update has not changed
my CPU from 428 to 42a, like Linux has when it
boots up. And not all of Linux would deliver
42a, only a recent distro shipped it. Others do not
at the moment. Everyone is scrambling to prepare.
https://www.intel.com/content/dam/su...rocidhelp7.gif
I'm just lucky I have one CPU where Jan.8 shipped
an actual microcode revision change I can detect.
If I had a P4, practically no experiment would
show that value changing from its "normal" value.
If your CPU isn't on the above list, there's not
much point in trying. If you attempt to load
an older microcode (416 for me), the CPU ignores
that. Only one higher than the current one (428),
will be accepted. And only after internally,
the CPU has vetted it (possibly RSA2048 protected).
Paul