CPU Security Flaws MELTDOWN and SPECTRE

Asus has been somewhat slow with the patches, though Station-Drivers does show quite a few released this week.
With the Github Meltdown release they are "under the gun", or should feel they are!
 
Maybe I should be thinking of getting my CPU microcode patched... Last I checked, ASUS hadn't posted any UEFI updates, but that was a good while ago now.

Fucking hackers, eh. This is why we can't have nice things, and so on... :???:
Depending on your OS and CPU you might already have the CPU microcode distributed via OS update
 
With the Github Meltdown release they are "under the gun", or should feel they are!
Holy shit, they didn't post updates until this week?! Bloody hell, they deserve to be fined for being so slow.

Depending on your OS and CPU you might already have the CPU microcode distributed via OS update
Hm, you sure windows updates can change CPU microcode? If we'd be talking about MacOS I wouldn't be doubting you, but surely microcode is stored in the UEFI, and that's mobo proprietary stuff - unless there's a common interface in the UEFI standard to do CPU microcode updates from windows?
 
Holy shit, they didn't post updates until this week?! Bloody hell, they deserve to be fined for being so slow.


Hm, you sure windows updates can change CPU microcode? If we'd be talking about MacOS I wouldn't be doubting you, but surely microcode is stored in the UEFI, and that's mobo proprietary stuff - unless there's a common interface in the UEFI standard to do CPU microcode updates from windows?
Microsoft has been releasing KB patches for Meltdown (repeatedly in some cases as it has caused other headaches), separately (Spectre orientated) some of the microcode updates I thought were also integrated into Microsoft updates but in a specific way and for specific OS platform:
https://support.microsoft.com/en-us/help/4090007/intel-microcode-updates
https://thewincentral.com/microsoft...eltdown-fixing-firmware-update-download-link/

It always seems a moving target between what Microsoft and Intel and motherboard manufacturers are doing and difficult to stay up with it all IMO.
 
Last edited:
Maybe I should be thinking of getting my CPU microcode patched... Last I checked, ASUS hadn't posted any UEFI updates, but that was a good while ago now.

Fucking hackers, eh. This is why we can't have nice things, and so on... :???:

I have an ASUS H170-Pro mobo and ASUS finally released a non-beta BIOS update a few weeks ago, and then another one right after that.
https://www.asus.com/us/Motherboards/H170-PRO/HelpDesk_BIOS/

Version 3610 2018/04/149.54 MBytes
H170-PRO BIOS 3610
1. Improve memory compatibility.

DOWNLOAD
Version 3606 2018/03/289.56 MBytes
H170-PRO BIOS 3606
1. Update CPU Microcode
2. Improve system security and stability

DOWNLOAD

Version 3601 Beta Version2018/01/029.56 MBytes
H170-PRO Beta BIOS 3601
1. Update skylake CPU microcode to version 0xC2, kabylake CPU microcode to version 0x7C.

DOWNLOAD
 
I updated my wife's Z97 ASRock BIOS last night with microcode patch. The BIOS was from mid-march, with the previous one from 2016.
 
Eight new Spectre Variant Vulnerabilities for Intel Discovered - four of them critical
News has just started spreading that researchers have sighted another eight Spectre like vulnerabilities in Intel processors, all resemble Spectre, four of them are critical. The new vulnerabilities are grouped and named as Spectre-ng. The newly discovered vulnerabilities would make it really easy to exploit a host from a simple VM.
....
Intel classifies four of the Specter NG vulnerabilities as "high-risk"; which in Intel language is translated as: super dangerous. The danger of the other four is rated as medium. According to c't/Heise, Specter-NG risks and attack scenarios are similar to those of Specter - with one exception. C't calls the Intel vulnerabilities and their procs a Swiss Cheese due to the many security holes.
http://www.guru3d.com/news-story/ei...r-intel-discovered-four-of-them-critical.html
 
Not sure where I read it, but despite named "Spectre-ng", they're supposedly Meltdown-related which is why they're not affecting AMD but do affect Intel and some ARM-cores
 
which in Intel language is translated as: super dangerous.
Fuck.

Hopefully this won't mean another kick in the nuts performance-wise.

Personally I'm starting to get a little bit pissed I spent a thousand bucks on a CPU only half a year ago roughly that's turning out to be a complete shambles security-wise, and has already lost a lot of performance.
 
Personally I'm starting to get a little bit pissed I spent a thousand bucks on a CPU only half a year ago roughly that's turning out to be a complete shambles security-wise, and has already lost a lot of performance.
You could probably sell it, get an equivalent performance AMD for cheaper and make a profit.
 
You could probably sell it, get an equivalent performance AMD for cheaper and make a profit.
Don't know if anything is gained since AMD is affected by Spectre and is subject to performance related issues.
Hauck Litigation
On January 19, 2018, a putative class action complaint captioned Diana Hauck et al. v. AMD, Inc., Case No. 5:18-cv-0047 was filed against the Company in the United States District Court for the Northern District of California. The plaintiff alleges that the Company misled consumers in connection with the marketing of AMD processors. Specifically, the plaintiff alleges that the Company’s processors cannot perform at their advertised processing speeds without exposing consumers to Spectre. The plaintiff seeks to obtain damages under several causes of action for a nationwide class of consumers who allegedly were misled into purchasing or leasing AMD processors (and devices containing AMD processors), as well as attorneys’ fees, punitive damages, and restitution.
Based upon information presently known to management, the Company believes that the potential liability, if any, will not have a material adverse effect on its financial condition, cash flows or results of operations.

Speck Litigation
On February 4, 2018, a putative class action complaint captioned Brian Speck et al. v. AMD, Inc. , Case No. 5:18-cv-0744 was filed against the Company in the United States District Court for the Northern District of California. The plaintiff alleges that the Company misled consumers in connection with the design and marketing of AMD processors. Specifically, the plaintiff alleges that the Company’s processors are subject to Spectre, and that any “patches” to remedy this security vulnerability will result in degradation of processor performance. The plaintiff seeks to obtain damages under several causes of action for a nationwide class of consumers and a subclass of Ohio residents who allegedly were misled into purchasing AMD processors (and devices containing AMD processors), as well as attorneys’ fees, equitable relief, and restitution.
Based upon information presently known to management, the Company believes that the potential liability, if any, will not have a material adverse effect on its financial condition, cash flows or results of operations.
24

Barnes and Caskey-Medina Litigation
On February 9, 2018, a putative class action complaint captioned Nathan Barnes and Jonathan Caskey-Medina, et al. v. AMD, Inc. , Case No. 5:18-cv-00883, was filed against the Company in the United States District Court for the Northern District of California. The plaintiffs allege that the Company misled consumers in connection with the marketing of AMD processors. Specifically, the plaintiffs allege that the Company touted the speed and reliability of its processors even though these processors are subject to Spectre. The plaintiffs seek to obtain damages under several causes of action for a nationwide class of consumers who allegedly were misled into purchasing or leasing AMD processors (and devices containing AMD processors), as well as attorneys’ fees, equitable relief, and restitution.
Based upon information presently known to management, the Company believes that the potential liability, if any, will not have a material adverse effect on its financial condition, cash flows or results of operations.
pg 24
https://seekingalpha.com/filing/4005344?uprof=82
 
You could probably sell it, get an equivalent performance AMD for cheaper and make a profit.
Find a buyer for CPU and mobo, tear down my entire PC, buy new hardware, rebuild it from scratch? No thanks... Too much work for a guy with my depression-induced inhibitions. :p From my perspective, I only just built this fucking thing.

I would accept a new socket-compatible CPU slug from Intel which has been fixed of errata though. I'm thinking there's a good case for forcing Intel to just replace peoples' already purchased product, especially with the performance loss we've already incurred and maybe further loss from this new latest shit. And who says it ends there?
 
Don't know if anything is gained since AMD is affected by Spectre and is subject to performance related issues.
Is that based on anything other than a spurious lawsuit which there are likely dozens after the release of the vulnerability info?
 
Is there something in particular on that page that you're pointing out? Communicate rather than just link spam everything.
Read the whole article and supporting benchmarks which show slight degradation for both Intel and AMD. The lag is felt on both Intel or AMD cpu's.

Their conclusion for both Intel and AMD processors was:
The current patch does have an impact on storage performance, at least when it's measured with synthetic benchmarks. A laggy hard drive would obviously affect level loading times and the storage subsystem's ability to feed the game engine, possibly resulting in choppy scene transitions. We scrutinized our load times and cut scenes closely, and while entry-level CPUs did take longer and were less smooth, it's hard to chalk that up to a security patch because slower processors are, well, slower. We didn't notice any dramatic changes in performance consistency or frame time variance, so any minor impact would likely be limited to storage-imposed symptoms, at least with the patches as they sit currently.
 
Why is it that switching between kernel and user mode has such a heavy performance impact anyway? From what I seem to recall reading, it involves flushing all registers/caches, but why do that if it means stalling the CPU for thousands of cycles each time? Couldn't - for example - metadata be added to cache lines to mark them as user/kernel and making them inaccessible unless in the correct mode, and thus let them stay in cache unless evicted normally, so that mode switching doesn't have such a huge penalty?

I'm sure there's good reasons for everything, but I thought I might as well ask... :D
 
Back
Top