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. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 |
|
|