A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows 7 » Windows 7 Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

GRC's Spectre and Meltdown testing software



 
 
Thread Tools Rate Thread Display Modes
  #1  
Old January 21st 18, 07:31 AM posted to alt.comp.os.windows-10,alt.windows7.general
Yousuf Khan[_2_]
external usenet poster
 
Posts: 2,447
Default GRC's Spectre and Meltdown testing software

Seems to be much easier than trying to install and run PowerShell
scripts, and much more reliable too:

https://www.grc.com/inspectre.htm
Ads
  #2  
Old January 21st 18, 07:57 AM posted to alt.comp.os.windows-10,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default GRC's Spectre and Meltdown testing software

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
  #3  
Old January 21st 18, 10:58 AM posted to alt.comp.os.windows-10,alt.windows7.general
Yousuf Khan[_2_]
external usenet poster
 
Posts: 2,447
Default GRC's Spectre and Meltdown testing software

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
  #4  
Old January 21st 18, 03:57 PM posted to alt.comp.os.windows-10,alt.windows7.general
Ed Cryer
external usenet poster
 
Posts: 2,621
Default GRC's Spectre and Meltdown testing software

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


I'm in the same situation regarding Spectre on my old Acer MB; on my
favourite, best-ever desktop to which I've added a large SSD and Blu-ray
drive, and kept Win7. And it's given sterling service over the years, so
I'll fight to keep it. Oh, and my BIOS goes back to 2011.

There must be zillions of computers around the world in a similar
situation. All vulnerable, so where are the cyber criminals and vandals
who will have heard about this like the rest of us? They could mop up
fortunes if they jumped in now.

Presumably they would have to get past firewall and AV to start
tinkering. So then, the usual caveats apply; keep your security up to
date, stay on your toes with emails and attachments, don't let an idiot
use your box of tricks. Oh, and pray that MS and the AV guys keep on
their toes with updates and AV definition releases.

Ed









  #5  
Old January 21st 18, 04:01 PM posted to alt.comp.os.windows-10,alt.windows7.general
EGK
external usenet poster
 
Posts: 103
Default GRC's Spectre and Meltdown testing software

On Sun, 21 Jan 2018 04:58:50 -0500, 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.


I agree. I have an older Gigabite board from about the same date and not
expecting a bios update for it. Intel also has to update firmware for the
cpu. Since my system is paired with a i5-2500k cpu I'm not expecting
anything for that either but am in a hurry to upgrade. That was one of the
best cpus intel put out in the last decade

I think inspectre is just reading the windows registry for the patch info
and either removing the entries or putting them back to disable/enable.
Antivirus makers had to add registry info as well.


https://support.microsoft.com/en-us/...virus-software
  #6  
Old January 21st 18, 04:09 PM posted to alt.comp.os.windows-10,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default GRC's Spectre and Meltdown testing software

On 21/01/2018 06:57, 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


A lot of it comes from the CPUID instruction, so directly from the
processor itself.

It's probably also looking to see which version of Windows you have and
at the registry to see if the fixes are applied.

--

Brian Gregory (in England).
  #7  
Old January 21st 18, 04:10 PM posted to alt.comp.os.windows-10,alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default GRC's Spectre and Meltdown testing software

"Yousuf Khan" wrote

| 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 don't see where anything says that. What
I've read is that so far there seems to be only
*mitigation* possibilities and those are
software-based.
The clearest rundown I've seen is he

https://www.extremetech.com/computin...ored-explained

If you get patches, the first question is whether
they're safe. So far there have been a lot of
reckless patch problems.

https://arstechnica.com/gadgets/2018...ks-get-closer/

Then there's the context. What does it all actually
mean? If you have AMD then the risk is that a program
can read random memory belonging to another program.
(Only meltdown can access kernel memory for a
general memory dump.) So, first you need a program
running the bug and a program running that has
sensitive data. Then you also need for the malware
element to be able to call home with sensitive data.

I think one of the demos showed
getting passwords from a password manager. That
might be a risk. Browsers are being updated to handle
it. Though there could ne issues there. For example,
FF 57 is patched, but FF 57 also breaks old-style
extensions. Personally I have no plan to update.

If you have malware with permissions running on
your system, or if you use a browser that can be
exploited, the next question is what vulnerable
information may be involved. In the first case, the
software already has local access, so it's not
likely to be an increased risk. In the case of
exploitable Internet-connected software, disabling
or limiting script will help. Beyond that? Maybe don't
use password managers. Maybe don't open multiple
browser windows when you're entering credit card
data. In other words, there is a risk, but the real
risk of what danger you might be in if javascript
in the browser reads random program memory is
very small. Most of what it can steal will be junk.
Some might be snippets of text. Very little, if any,
will be your phone number or credit card number.
And to a great extent you can plan for that by
simply not running your tax software at the same
time you load webpages.

I've been finding it hard to get full info on all
of this, but that seems to be the facts as far as
I can figure.

What may be more of a risk is phones. It now
turns pout most cellphones are vulnerable. It's
very difficult to control security on phones. A
lot of malware apps get through. A lot of sensitive
info may be stored. On the other hand, anyone
putting sensitive info on a phone is asking for
trouble.


  #8  
Old January 21st 18, 04:15 PM posted to alt.comp.os.windows-10,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default GRC's Spectre and Meltdown testing software

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.

--

Brian Gregory (in England).
  #9  
Old January 21st 18, 04:30 PM posted to alt.comp.os.windows-10,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default GRC's Spectre and Meltdown testing software

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.

--

Brian Gregory (in England).
  #10  
Old January 21st 18, 04:41 PM posted to alt.comp.os.windows-10,alt.windows7.general
s|b
external usenet poster
 
Posts: 1,496
Default GRC's Spectre and Meltdown testing software

On Sun, 21 Jan 2018 04:58:50 -0500, Yousuf Khan wrote:

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.


Same here. AMD A8-3870.

| Vulnerable to Meltdown: NO
| Vulnerable to Spect YES!
| Performance: GOOD

Latest BIOS is dated 2014.

--
s|b
  #11  
Old January 21st 18, 10:49 PM posted to alt.comp.os.windows-10,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default GRC's Spectre and Meltdown testing software

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
  #12  
Old January 22nd 18, 12:54 AM posted to alt.comp.os.windows-10,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default GRC's Spectre and Meltdown testing software

On 21/01/2018 21:49, Paul wrote:
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.


Then why is everyone saying we need to update our BIOSs?

I pretty sure Steve himself said in the podcast that Microsoft hadn't
updated the microcode in Windows for years.

--

Brian Gregory (in England).
  #13  
Old January 22nd 18, 01:13 AM posted to alt.comp.os.windows-10,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default GRC's Spectre and Meltdown testing software

On 21/01/2018 23:54, Brian Gregory wrote:
On 21/01/2018 21:49, Paul wrote:
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.


Then why is everyone saying we need to update our BIOSs?

I pretty sure Steve himself said in the podcast that Microsoft hadn't
updated the microcode in Windows for years.


Sorry, forgot which newsgroup I was in, I mean Steve Gibson of GRC.COM.

--

Brian Gregory (in England).
  #14  
Old January 22nd 18, 01:24 AM posted to alt.comp.os.windows-10,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default GRC's Spectre and Meltdown testing software

Brian Gregory wrote:
On 21/01/2018 21:49, Paul wrote:
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.


Then why is everyone saying we need to update our BIOSs?

I pretty sure Steve himself said in the podcast that Microsoft hadn't
updated the microcode in Windows for years.


*Microsoft* is saying, "if you want microcode now"
(if you're providing an AWS server for people to rent),
"you should get a new BIOS from your motherboard company".

People who run Cloud servers, have all installed BIOS
patches. Because that is the "belt and suspenders" answer.
They're doing their upmost and the moment, to avoid trouble.

For home users, the combination of "only 2013 or later processors
are patched", plus the Microsoft "we aren't delivering Jan.8
microcode right now", means that only a few people will
take the BIOS route. If you're running a server and renting
computer time to people, you should use a BIOS. Your machines
aren't going to be any more than three years old anyway.

But for the rest of us, from a percentage perspective,
only a very few will be able to follow the BIOS advice.
Even though I got Linux microcode when booting a
sample Linux install, my motherboard maker will not
be providing a new BIOS, so I cannot protect myself
when running Windows 10. At the moment...

My best Spectre patch-ment at the moment, is to be
running Firefox 57.0.4 or later. Make sure your
browsers are patched. Maybe 85% of computers, that's
what we'll be doing to protect them. Patching
at the application level, as best as possible.

If your motherboard company has a new BIOS for you,
your CPU is not Broadwell or Haswell, then perhaps
a BIOS upgrade is possible. At the very least,
your motherboard should have a "forgiving" BIOS
upgrade process. Mine accepts a USB stick, and
the chip on my motherboard, can change the BIOS
even when no CPU is in the socket. Now, that's
an ideal form of non-brickable BIOS feature.
Too bad there's no new BIOS file for me to use :-(
As I have the hardware to do this risk free.

Other systems, there is more risk. A Gigabyte
dual BIOS user might be able to risk it,
as an example of another kind of protection
that can afford brickage under a few conditions.

On regular unadorned BIOS setups, if the microcode
somehow prevents the BIOS from running, you
can't inject the old BIOS any more. You need
a table-top flasher to fix that. While brickage
is not likely to happen, I feel it only
fair to describe what could happen. Foe example,
I could spill a cold beverage in the computer
while half-way through the flash, flip off
the power in the ensuing panic, and because
the BIOS flash is half completed, the computer
will never boot again.

At the very least, use a UPS if flashing the BIOS!!!
A laptop has a natural UPS, in the form of the
battery pack. If you flash a laptop, that's
your "power backup". A desktop has no protection,
unless you provide it externally (UPS).

Paul
  #15  
Old January 22nd 18, 03:41 AM posted to alt.comp.os.windows-10,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default GRC's Spectre and Meltdown testing software

Brian Gregory wrote:
On 21/01/2018 23:54, Brian Gregory wrote:
On 21/01/2018 21:49, Paul wrote:
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.


Then why is everyone saying we need to update our BIOSs?

I pretty sure Steve himself said in the podcast that Microsoft hadn't
updated the microcode in Windows for years.


Sorry, forgot which newsgroup I was in, I mean Steve Gibson of GRC.COM.


That's not true.

As one of my test cases, I booted a Linux LiveCD, one
a couple years old, and the microcode level was 16.

The Windows 10 16299.192 microcode level is 28.

The very latest Linux one available, is 2a.

Microsoft *is* providing OS level microcode, just
not using the January 8, 2018 version quite yet.

Neither is Linux, on all distros. Only the most
modern got it so far. Linux in the distro package
manager, provides a separate line item for
"microcode.dat", and presumably selecting that
does whatever magic is needed to make an initrd
or similar. You would look in your package manager,
to see if perhaps the microcode had been recently
updated. In the Ubuntu test VM, I could indeed see
the word "microcode" in a list of 500MB worth
of patches. It was an item in there. I saw it fly by.

And in Linux, I have a couple ways to check. Via
dmesg | grep microcode, or via looking at
cat /proc/cpuinfo or similar. Since I know some of
the available revision numbers for my CPU, I'm able
to tell whether a January patch was installed or not.

If I had a P4, there'd be nothing to see, and the
same old crusty microcode version would be present
for all of the above test cases. Even a BIOS flash
wouldn't help, because Intel has no specific help
for a P4. And there are lots and lots of computers
out there which are more than four years old.

Even if you "had all mitigations", at this point
I wouldn't be too smug about it. This story
isn't finished.

*******

"Update your BIOS" is good if you're the owner
of AWS or Google Cloud or the like. Any place you
have no control over the computing that goes on,
the "attack surface" is huge. You want hardware
protection (if you can get it). Cloud providers have
been installing BIOS, even if it costs 20% performance
on some I/O intensive workloads.

The situation for at least some home users is a bit
more benign. The main threat surface is their browser,
and their browser has received a patch. That's a
start.

And the "need" to get a BIOS, will be relieved,
once Microsoft un-gates the Jan.8 microcode into
the wild. Linux has already done those, for at least
one distro. I feel Microsoft will eventually do it too,
and once it does, you won't have to run off and
flash the BIOS.

The OS microcode loader does work. In my tests,
an old Linux was 16. In Windows 10 16299.192,
the version was 28 on my machine. That means
probably a microcode from Fall 2017 or so. And
eventually, when Microsoft "un-gates" the Jan.8
microcode, my machine will leap to 2a hex.

On an older machine, the P4 running Windows 7,
*nothing* is going to make it leap. You install
Firefox 57.0.4 (i.e. do your browser patching),
and that's basically the only option available.
There will never be a BIOS. When the Jan.8 microcode
is released, your P4 will have the "same old
revision number" it always had.

Paul
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 11:16 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.