Read more.Quote:
And AMD has supplied microcode updates to partners for CPUs dating back to 2011.
Printable View
Read more.Quote:
And AMD has supplied microcode updates to partners for CPUs dating back to 2011.
Would be nice if they had given an actual version number to look for. Mine seems to be from mid December still:
$ rpm -q -f /usr/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
linux-firmware-20171215-82.git2451bb22.fc27.noarch
$ cat /proc/cpuinfo | grep "microcode" | uniq
microcode : 0x600084f
Last BIOS from ASUS was 2015, so I won't hold my breath for them to release an update.
One for the true nerds out there....
... given the performance impact of these patches (Anandtech did an analysis and the hit to NVMe drive performance is horrific) I personally think informed users should be allowed to decide on whether the patches are installed. Is there any way to prevent their installation on a Windows 10 system or to remove them and stop them coming back?
Do you have a link we can check out those horrific performance?Quote:
Originally Posted by philehidiot
You could try: https://www.grc.com/inspectre.htmQuote:
Originally Posted by philehidiot
Are you sure the performance issue impacts spectre patches for AMD and not just meltdown patches for intel? The media has been pretty poor at explaining that distinction, much to intel's delight I'm sure. Everything I've seen so far indicates no performance loss for spectre patches on any platform, that could have changed of course.Quote:
Originally Posted by philehidiot
You're possibly right and I've got it all upside down and backwards. I'll have a look later on tonight and get back to you.Quote:
Originally Posted by EN1R0PY
Okay, for those questioning my competency, well here's the evidence you need to prove you right.
https://www.anandtech.com/show/12566...ntel-nuc7i7bnh
The analysis was done on BOTH vulnerabilities (discriminating between no patch, OS patch and OS and uCode) and solely on an Intel platform.
My question is still valid although perhaps in a broader domain. Given there is a hit to performance, is there any way to keep Windows up to date but choose not to install these patches?
To the person asking about the "horrific performance" - see page two of the link above and scroll to the bottom graph. It demonstrates clearly there is a massive impact on NVMe performance whilst most other hits will be negligable and affect niche users. NVMe performance is hit by 29% - for that you might as well have saved your money and got a SATA based SSD.
IIRC there's a switch in the registry that can be used to turn it on/off, that i won't link to in case i get accused of saying people should do it. ;)Quote:
Originally Posted by philehidiot
Having said that IDK how or even if switching the protection on/off at the OS level effects performance with or without a microcode update.
Not installing the patches would be safe if you unplug the network cable. If the network cable is unplugged then you won't be getting the patches so you won't see a drop in performance. Problem solved.Quote:
Originally Posted by philehidiot
And people running Windows 7 should be aware that Microsoft messed up the January patch for them so getting those machines up to date is really important. This is why, like the OS or not, if you are going to run a Microsoft OS make it the latest one because the older operating systems just won't get the same level of attention: https://threatpost.com/bad-microsoft...secure/130844/
But basically, most people only really care about Windows performance with gaming which really isn't hit. The hit to storage benchmarks isn't reflected in any Windows application benchmark I have seen. Just patch, it isn't worth avoiding it.
FWIW one of my boxes is a Linux box that is hit quite hard by these patches. It is bang up to date and despite the benchmarks I can't feel any difference.
Looking at the link will give you some idea but they did not test just the microcode without the OS update being active.Quote:
Originally Posted by Corky34
Personally, I doubt it'll affect me but equally I think people should have the option to disable it as long as they are aware of the risks. Hell, I did something similar to someone's pacemaker yesterday. I just ensured she was aware of the risks and she was willing to undertake them for the perceived benefits.
My Apple machine has recently taken a dive in performance but equally, the update that has been applied just happens to be the last one as it was declared obsolete. Coincidence?Quote:
Originally Posted by DanceswithUnix
Given Apple's record I'm willing to guess it's no coincidence.
Time for that full Kali install then.
The link was one snapshot of patching, one CPU, one operating system. More modern CPUs will take less of a hit, and the patches will get better over time as new tricks are pulled. Then there is the concept that related issues are going to be creeping out over the next couple of years, and really you want the patches applied before they are announced.Quote:
Originally Posted by philehidiot
Really, unless your workload is copying lots of small files around SSDs all day on Linux/Mac systems with a really old Intel CPU then you aren't going to take a hit by patching. Being more informed than that? Well that means at least detailed benchmarks of your specific machine or if you have several then knowing how results along axes of cpu age, operating system and level of patching which might get you an interesting 3D density map on a 3 axis graph but personally I think it is just too much effort to track that moving target when the correct thing to do in the face of overwhelming data is just patch.
Hmm, the system tested was a Kaby Lake U, interestingly though I have to question the storage benchmark as the NVMe seems rather slow already (even for a 128GB capacity). So the only real take away from that test is that anything I/O intensive is going to take a hit when patched on an Intel system.Quote:
Originally Posted by DanceswithUnix
Not that I'm remotely concerned about getting any form of microcode update for my hardware, considering the response I got from Gigabyte was,
Be interesting to see if there are any differences on AMD systems in terms of the I/O impact.Quote:
Currently, we haven’t get the new MCU from Intel yet, so we still have no new BIOS for 6 series motherboard.
Only I/O done in small amounts, like small file copying. Windows was always pretty bad at that anyway which is why the initial scary numbers which came from the Linux community never materialised. It isn't the I/O that is the problem, it is the rapid fire operating system calls needed to set it up because the switch from user to supervisor and back just became more expensive, and on old platforms where you can't get help from the VM support a lot more expensive.Quote:
Originally Posted by Iota
The Linux community have also found some database applications hurt, AIUI that isn't actually the database it is the network chatter through the loopback network connection.
The operating system should patch the microcode for you on every boot if the BIOS didn't leave it up to date. Microsoft have suspended doing that for all AMD platforms after some trouble with the last Athlon update but I'm sure that will all get sorted out.Quote:
Not that I'm remotely concerned about getting any form of microcode update for my hardware, considering the response I got from Gigabyte was,
Be interesting to see if there are any differences on AMD systems in terms of the I/O impact.
The big hurt for performance here is Meltdown on *older* Intel systems, and AMD isn't effected by that so the performance hit is minimal. I believe these recent microcode updates aren't mitigations as such, but new barrier instructions that the operating system can use as tools for mitigation. So the microcode on its own will do approximately nothing, and then operating system code will change over time giving you something really hard to measure.