Kitz Forum
Announcements => News Articles => Topic started by: roseway on January 03, 2018, 06:44:11 PM
-
A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ (https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/)
-
There's going to be a lot of very annoyed users if we do see a 30% performance hit. I won't be happy having invested a lot in many Intel systems if they all slow down.
-
I was reading random stuff about this earlier. Thought I saw a mention that MacOS had already released a fix, presumably without disclosing what it did. I can’t find that story again, maybe I imagined it. But if true, the relevance would be that I don’t remember any complaints about Mac performance after recent updates?
Danger is that whilst the 30% hit makes a great news story, it also becomes a self-fulfilling prophecy. We all know that systems often appear to degrade over time as people install more and more rubbish. After this, they’ll have a scapegoat to blame for such degradations...
-
That's handy that I've been running AMD processors now for some years on my desktop. Sadly I do have 3 Intel laptops, all running Linux.
Stuart
-
The register thread was fascinating. Virtual memory handling seems like skating on ice. In olden days, VM "worked" if stuff ran (by the skin of its teeth) without crashing. Nowadays, the security side is so much more important, and the attack-surface so much larger, and prominent. Winging it doesn't work. Processor design seriously needs a dose of the quivering horrors, and more professional attitude. With floating-point units, that happened in the 90's, but only because the alternative was stingingly expensive (for Intel again, IIRC). Let's hope this is expensive too.
I'm not sure (phones? central heating?), but the only amd cpu in the house that I'm aware of is a raspberry pi. Bloody hell. And who knows what lurks in that.
-
Have to say, I have no idea what CPU lurks within my smart TV, or my smart Blu Ray player, both
Linux based and fully exposed to the big bad Internet. Still under warranty so I will resist taking them apart to see what’s inside.
Even if they are Intel, I certainly shan’t be pinning my hopes on a kernel update. :(
-
... fully exposed to the big bad Internet. ...
What, no firewall blocking unsolicited input?
Brave, very brave.
-
What, no firewall blocking unsolicited input?
Brave, very brave.
Firewall is largely irrelevant here.
Of course I have a NAT firewall that would make incoming attacks difficult, but I have no control over the exchanges that are initiated by the devices themselves. I know the TV phones home to Panasonic for example, each time I try to access Netflix, though I don’t know why. Out of the box, it phoned home even when I simply switched freeview channels, though I figured out how to disable that.
Even without phoning home, I regularly view sources such as Netflix and IPlayer. We should not rely on that material, or the data that is streamed, to free from malware.
These devices also run a whole proliferation of third party Apps, some I have installed, some came bundled. I use hardly any but I have no idea how or why these Apps might be launched, or what sort of traffic exchanges these Apps may initiate.
-
Intel Responds to Security Research Findings (https://newsroom.intel.com/news/intel-responds-to-security-research-findings/)
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.
Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.
Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
:-\ :-X
-
With Apols to B’Cat, as I see his post has crossed while I type....
Intel’s response.
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Time will tell but sounds to me like they are in a rather dangerous denial mode, and very afraid.
They name AMD and ARM as if to imply them too, in carefully chosen words that say nothing slanderous (probably), but possibly a well contrived smoke screen.
Then again, the whole story has yet to emerge. Let’s watch with interest.
-
With Apols to B’Cat, as I see his post has crossed while I type....
b*cat performs one of his best Japanese style bows in 7LM's direction.
Time will tell but sounds to me like they are in a rather dangerous denial mode, and very afraid.
They name AMD and ARM as if to imply them too, in carefully chosen words that say nothing slanderous (probably), but possibly a well contrived smoke screen.
So I am not the only one to "sense those vibrations".
Then again, the whole story has yet to emerge. Let’s watch with interest.
Yes, definitely. Who knows what may eventually "scuttle out of that hole".
-
MS Patch for Win 10 released today.
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892
Use at own risk but my 2 machines seem ok.
-
There is some interesting discussion at https://forums.freenas.org/index.php?threads/intel-is-well-and-thoroughly-screwed.60331/
One person with cloud contacts believes that the cloud industry is in a panic about the performance impact.
As with the Atom problem, Intel seems to be relying on NDAs again to try to keep the lid on. Vis this in a recent FreeBSD security announcement:
The FreeBSD Security Team recently learned of the details of these
issues that affect certain CPUs. Details could not be discussed
publicly, but mitigation work is in progress.
Intel's CEO selling $24 million of shares after the problem became known to Intel seems rather iffy too. http://uk.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1?r=US&IR=T
I already have 4 Atom based machines machines (NASs and firewalls) with their probably shortened life. Now it looks as if they, and the rest of my stable of desktops and a laptop, may start to have performance problems.
As I recall, Fred Hoyle and John Elliot's 1961 A For Andromeda mentions a different organisation called Intel as being most evil. Prescient.
-
Firewall is largely irrelevant here.
Of course I have a NAT firewall that would make incoming attacks difficult, but I have no control over the exchanges that are initiated by the devices themselves. I know the TV phones home to Panasonic for example, each time I try to access Netflix, though I don’t know why. Out of the box, it phoned home even when I simply switched freeview channels, though I figured out how to disable that.
Even without phoning home, I regularly view sources such as Netflix and IPlayer. We should not rely on that material, or the data that is streamed, to free from malware.
These devices also run a whole proliferation of third party Apps, some I have installed, some came bundled. I use hardly any but I have no idea how or why these Apps might be launched, or what sort of traffic exchanges these Apps may initiate.
Mmm, yes. Who knows what software is telling, and getting, when it phones home.
-
Luckily I still have a non-smart TV. If I have to get a new one I suppose I can either refuse to allow it into the LAN, or segment it off somehow onto a second, untrusted LAN, so as to stop it from getting near my other boxes or even attacking LAN infrastructure.
There is definitely going to be some serious arse-kicking at Intel, I would hope. What were they thinking? I wonder about sneaky unchecked writes to supervisor space?
I know all about what speculative execution is, even though I am a very old machine code programmer, but I would very much like to see some of the Dutch PhD student’s code to give me a concrete example.
I am hoping that Intel will put in a 'bug fixed' flag in CPUID, so that operating systems can skip all the wasteful nonsense that they are having to put in just now. I wonder if they have already made such a definition now ahead of time, so o/s's won't have to be re-released yet again merely to pick up the CPUID awareness thing. It would also be nice if we could have a boot option to opt out of this mod for the special case where if we only ever have trusted code in our boxen. And I'm assuming the o/s designers will put in a different code path, or better a different build altogether, for AMD CPUs right now.
If it is true that Apple has already fixed the bug (when?) then perhaps the performance impact isn't quite as bad as asserted (seeing as no-one has complained), or perhaps the hit is only as bad as 17%-30% or whatever if you have a peculiar app that does a huge number of ring transitions to kernel mode.
-
I did consider just disgregarding the smartness of my TV, denying it access to Lan. Netflix, Iplayer etc can, after all, be provided by a separate STB that is cheap enough to replace every few years, thus keeping it up to date. Trouble is, the draw of having Netflix & Iplayer fully integrated was too strong, it is just too convenient.
So I relinquished, but put the TV on my ‘guest’ Lan, where devices are isolated from from other Lan devices, can only access the internet. But owing to my specific current equipment, a limitation arose - the only way to view my photos at 4k resolution, was to use the TV’s own photo App, so the TV needed access to my media server. And the battle to secure the TV was lost. :(
-
Hmm, AMD do seem to be softening their denials, sounds like they are hit too. Arm also. Slashgear story includes statements from both...
https://www.slashgear.com/intels-bug-response-its-not-just-us-03513499/
More from AMD here...
https://www.amd.com/en/corporate/speculative-execution
Strikes me that ARM would be a pretty big problem, owing to use in smartphones. Smartphone performance might well to tuned so as to depend upon every last CPU cycle, being a much more controlled and predictable environment, compared to a standalone PC.
-
sevenlayermuddle: Would it be feasible to use a switch or firewall to restrict your TV to being only able to access the media server within your LAN? (Plus it will need to talk to the DHCP server probably, and probably the default gateway)
I have changed the firewalling scheme that is in use in my Firebrick so that I can have more classes of citizens, not just a binary arrangement if guests=pond-life or first-class citizens, but now I can have guests who can't pester first-class citizens, nodes that have assigned fixed IPv4 addresses [fixed values but still handed out by DHCP], nodes that are restricted to very slow internet access and so on, and these properties/restrictions can be much more easily be set separately rather thatn just being determined by the two-caste system. It's all driven by lists of MAC addresses in the Firebrick and in the ZyXel WAPs.
-
@Weaver, yes I am sure more could be done to secure my TV with special rules. Trouble is, it all takes effort, and my time is limited.
Another convenience I’ve not yet mentioned is my Panasonic camera can talk direct to a server provided by the TV, directly displaying new photos over WiFi. Handy when I get back from a day out and just want to preview from the armchair. That wouldn’t work on my guest Lan, as devices are isolated from one another. Again, special rules could probably be established, if only I had the time, but I don’t.
-
It is indeed all a pain, the time it takes to keep these things well tamed.
-
Google say ARM and AMD are affected too, not just Intel.
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
-
According to that AMD response they are only potentially at risk from 1 of the 3 variants and the one they say they are at risk of is resolved by updates to the OS. Although they are being careful about variant 2 where they say near zero risk. Which sounds to me like their hardware/firmware is more resilient than the Intel stuff.
Stuart
-
Suddenly they are falling over one another in attempts to explain the situation. I guess the NDAs must have expired.
Sounds like Google found it and shared it many months ago, so all very well understood. Similar can (I think) be found from Google, AMD and Intel, but I found ARM’s white paper very readable. If my grey matter was 10 years younger, I might even have grasped it all from first pass. Meanwhile I will continue reading over and over, in the hope it sinks in. :)
https://developer.arm.com/support/security-update
White paper, linked from above...
https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf
-
I would have thought that the cache timing thing is difficult to use practically.
I remember timing side channel stuff going back many years, it's hardly true to say it's a new general principle, but this particular application if it is new. I remember for example discussions about analysing timing of requests sent to a server, and such timing analysis could tell you whether an object was in a disk cache in a server or not, and intentional response-timing manipulation was suggested as a covert means of sending information out despite a blocking firewall. Basically, if you are living inside a firewall boundary, you thrash some box that is acting as a server and your friend outside makes allowed requests on that server and times the responses. By thrashing or not thrashing you can make the responses arrive back at your friend early or late so then you can send one bit of information out. Standard error correction helps.
-
that performance hit is huge, surely they need to make some kind of optional flag/setting in the OS to give end users the choice.
-
https://meltdownattack.com/
and...
https://spectreattack.com/
-
I notice that the paper linked to earlier claims that the Spectre timing attack has been successfully tested on some ARM processors and on the AMD Ryzen. So Intel isn't the only one in the doghouse.
-
Here follows a copy of a post that Linus Torvalds made to the Linux Kernel Mailing List --
Why is this all done without any configuration options?
A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.
I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.
.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.
Or is Intel basically saying "we are committed to selling you p00
forever and ever, and never fixing anything"?
Because if that's the case, maybe we should start looking towards the
ARM64 people more.
Please talk to management. Because I really see exactly two possibibilities:
- Intel never intends to fix anything
OR
- these workarounds should have a way to disable them.
Which of the two is it?
Linus
https://lkml.org/lkml/2018/1/3/797 (https://lkml.org/lkml/2018/1/3/797)
-
So Linus agrees with me. Good for him. We don't all need this nightmare fix, but that is not to be understood as a recommendation for complacency. I also think it's time to take a careful and considered look rather than panicking. And the advice of people such as Linus is to be heeded, not those who have a political axe to grind.
Saying that something performs to spec is not good enough if the spec is insane, remember was the Airbus plane that put its wheels down when it went over the top of a hill, because that was the "definition" of "landing", and then crashed.
-
I notice that the updates have been rolling out.
2018-01 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4056892)
Successfully installed on 04/01/2018
KB4056892 (OS Build 16299.192) (https://support.microsoft.com/en-gb/help/4056892/windows-10-update-kb4056892)
I've not noticed any performance issues but to be fair Ive not stressed it out or done any testing. There is a large thread on tenforums (https://www.tenforums.com/windows-10-news/101607-cumulative-update-kb4056892-windows-10-v1709-build-16299-192-a.html) where users have been doing more advanced testing. From a very quick scan through that 15 page thread, apart from someone mentioning ASUS I couldnt see anything too negative.
---
ETA just noticed a post added a few mins ago here (https://www.tenforums.com/windows-10-news/101607-cumulative-update-kb4056892-windows-10-v1709-build-16299-192-a-15.html#post1255098) about someone's SATA performance.
Damn. This "fix" has completely killed my SATA SSD performance:
I couldn't believe it but I reinstalled the patch and got virtually identical results.
Yet bizzarely, an NVM-based SSD on the same machine is completely unaffected. A driver thing I guess.
-
It’ll be interesting to see where people stand re legal rights, such as Sale of Goods Act. I don’t see how anybody could deny this was a manufacturing defect so, if any device ceases to perform as expected, ie it runs a lot slower, and the seller is not able to fully restore performance, might there be a claim?
Perish the thought, but just as the PPI scam phone calls begin to subside, might there be a new version.... 4 or 5 times a day... ring, ring. Recorded voice: “Is your computer running slower? Did you know you may be entitled to a refund...? Press 9 now, to claim your refund. “. ::)
-
https://downloadcenter.intel.com/download/27150 (https://downloadcenter.intel.com/download/27150)
Check that link out. It's a program that will tell you if your intel cpu is vulnerable. According to that my i7-7700K is vulnerable. Yet my old i5 2500K isn't vulnerable!
This is the video link I got it from, Britec: Your Intel CPU Could Become Up to 30% Slower https://www.youtube.com/watch?v=2fKXQIEO67s (https://www.youtube.com/watch?v=2fKXQIEO67s)
-
A couple of papers, for those who would like some easy bed-time reading --
https://gruss.cc/files/kaiser.pdf
https://meltdownattack.com/meltdown.pdf
-
https://downloadcenter.intel.com/download/27150 (https://downloadcenter.intel.com/download/27150)
Check that link out. It's a program that will tell you if your intel cpu is vulnerable. According to that my i7-7700K is vulnerable. Yet my old i5 2500K isn't vulnerable!
I’m not entirely convinced that tool relates to the topic of this thread. A genuine tool, for this or a different problem, or just a deliberate Intel smokescreen, who knows? It seems to predate by a few weeks, wheras NDAs were obviously in place regarding the real issue. They certainly would have known the story was going to break this week, plenty of time to plan in advance distraction in tactics.
Happy to be proven wrong, above is more hunch than anything else.
-
We are going to have to move to a world where only non-malicious software is allowed into our boxes. This isn't a problem for most people because they don't have any apps that are trying to thieve information from places they shouldn't be trying to access. The costs of “security” amounting to paranoia should not be allowed to wreck performance for the 99.9999% normal case. It's going to be far cheaper to simply forbid evil code from coming into your system.
So how to do this? Microsoft has done a lot of research on this over recent years. Security by proving that code isn't evil. This can be expensive but only has to be done once done processors are getting faster and more numerous, and the latter property could be used to attack the problem of correctness-checking code by dividing up some of the workload across multiple cpus. In many cases though, correctness checking isn't even needed as you just get your apps signed from a trusted source. If you correctness check them, you can sign them as checked afterwards.
This still means that interpreters / jit compilers that can take in arbitrary code must be treated with special handling. But signature+origin checking or correctness checking will still do fine for these cases, just moved up a level to the code you're importing and interpreting. (eg the Spectre + javascript compiled to machine code example.)
This good-code-only world is like ios, a tyranny. That's why I use ios now, despite it being incredibly annoying and unnecessarily crippled in every respect due to the confusions created by mobile phone assumptions which make no sense on ipads.
In the 1970s and early 1980s you simply didn't have evil apps running on your mainframes of VMS boxes and iirc some manufacturers would possibly check software products for you so that you could be confident that new software wouldn't ruin your life.
I have never run any antivirus on my customers' windows boxen because there was absolutely no need. I just made absolutely sure that there was no code on the box that shouldn't be there and no mechanisms at all for importing executables or interpreted code. This was done using low-privilege plus SRP and a load of other specially designed group policy restrictions, and email scanned server-side, the sum of which meaning that users could not import code from removable disks and run it, run it after a download or receive it in email. SRP meant that only code installed intentionally by a highly trusted expert admin could be run at all. Users were not allowed to create folders in arbitrary locations, and no unpapproved directories that we're children of the root could be created. Any children of root directories that shouldn't be there were just deleted automatically, in case installation programs created them using privilege. And any exe or dll files in the wrong place were similarly burned automatically (either deleted or renamed with a safe extension so they could be examined) - this was to prevent users from spreading evil, or needed to protect them as they couldn't run such things anyway, because of SRP and ACLs.
So no crashing due to bugs in resident antivirus nor the associated gruesome slowness. And no waiting for the antivirus to simply fail anyway or be disabled by evildoers. Every infected machine I ever saw (non-customers of course) had antivirus on it.
I did still use antivirus software for _scanning_ unknown files bug only as part of audits to make sure that things were as they were supposed to be. I have no problem with scanning tools as long as you don't rely on them because they aren't resident and interfering with the o/s and apps and making the machine ill and slow.
I never had any kind of security incident on any of my customers machines, despite best efforts by users. Users were never allowed to be admins under any circumstances and that was that.
I found the walled garden approach very very effective, full performance and zero crashes and stuff running as Microsoft tested it, not perverted with alien av code making it ill and introducing breakage of assumptions.
Apologies for the length and pomposity + self-promotion of this rant. I feel better now. Nurse, my pills?
-
Weaver I agree but the core windows design is oblivious to that.
You have 3 wrappers on the windows OS as an example
rundll32
svchost
runonce
Malware can choose to access the internet via say rundll32 and bypass whitelist mitigations. This flaw has stayed in place from windows 95 to today I assume for backward compatibility reasons. Its very old legacy vulnerable code, to show how old it is, Microsoft still have to keep MS-DOS 8.3 filename support enabled on C: by default because rundll32 needs it.
Microsoft windows has an excellent whitelisting tool built in called applocker, its absolutely amazing. But only works on enterprise versions of windows as microsoft consider it a "corporate" feature. It was also enabled in windows 7 ultimate, but there is no ultimate for win8 and win10. SRP does the same (remember cryptolocker which uses it?) but SRP is no longer supported by microsoft, has some unresolved bugs and is less user friendlly to use. Applocker has a wizard which will scan your app directories and auto whitelist whats there.
I personally use all of the following, I currently have no a/v installed as I consider that very obsolete and ineffective practice. Although a/v that scans emails I still consider useful so it may get reinstalled at some point (my laptop still has a/v on top of what I list here).
Registry tweaks that do the following.
Disable SMBv1
Disable NTFS encryption (anti ransomware)
Disable powershell, vb scripts etc.
Prevent dll's from non system folders overiding system dll's.
DEP default on for 32bit processes (stock is default off, DEP is enforced on all 64bit processes regardless, so yes 64bit browsers are natively more secure than 32bit browsers)
ASLR, SEHOP enabled.
Also
Secure boot enabled
Anti exploit software currently I use hitman pro alert for this.
SRP whitelisted binaries policy as well as whitelised dll's this took a fair amount of time to configure, but it makes things very difficult for attackers.
Filter outbound traffic (windows default is to allow all silently).
My network via pfsense blocks traffic to known malware control ip's, compromised domains etc.
My network via pfsense enforces DNS queries via trusted DNS servers.
Whitelisting of binaries, dlls is clearly the way forward, but the industry will resist it as the security software market is huge, if the OS becomes secure, then the likes of ESET and kaspersky go out of business.
Even with whitelisting memory exploiting is becoming a bigger issue with every passing year, thats what exploit protection is for, the likes of DEP etc. are designed to mitigate the risk. These cpu exploits fall into this category.
Windows 10 has made some strides, Windows Defender (or whatever its called now), now implements exploit protection (based on what is in EMET), but has no proper whitelisting, which microsoft still see as a corporate only feature.
HIPS aiso an effective form of security (behaviour blocking), this is similar to what selinux does in linux. Currently windows has no native HIPS.
-
@Chrysalis - I had all my customers on Ultimate or Business products or whatever they were called that or the corporate SA releases, but Ultimate especially for home use as home environment is even more evil with working parents who used to let their kids have their own logins on the same box.
I'm so out of date now, after I retired when I was administering Windows 7 boxes, I hated Windows 8 so very much that I completely gave up on MS products and went Apple for my own use. I've never even seen Windows 10 for instance.
-
Weaver I moved to win 8 as there is now fixes or workarounds for most of the issues that made people hate it and there is some important enhancements.
Windows 10 also has enhancements, but the behaviour of the OS is horrific, with all the telemetry, enforced updates, settings been lost after updates and so on. I just consider it nowhere near suitable for my main PC or laptop. With this OS microsoft have resorted to treating their end users like toddlers.
If it wasnt for gaming I would probably be using linux now.
-
Seems to be confirmed that Apple released the mitigations ahead of time.
Apple update
https://support.apple.com/en-us/HT208394
As far as I can see, 10.13.2 (& equivalents for earlier OS versions) for macOS was released at start of December affecting various listed issues. The release notes were updated this week to also mention these vulnerabilities. I guess that allowed them jump the gun with the fixes, without breaking the NDA that was obviously in place.
About 10.13.2
https://support.apple.com/en-gb/HT208331
I do not remember hearing any reports of performance problems with 10.13.2, which is encouraging.
Since late November I have occupied myself evaluating, and playing with, different photo processing software which is often highly CPU intensive. Slow enough to be slightly annoying even on my spanking new iMac. I did not notice any step change in speed.
-
Interestingly I just read a post elsewhere which suggested that there was general agreement to disclose these issues on the 9th January 2018, however Linux jumped the gun and made it public earlier which seems to have led to this flurry of information. If true maybe they did not do an NDA on Linux?
Stuart
-
Interestingly I just read a post elsewhere which suggested that there was general agreement to disclose these issues on the 9th January 2018, however Linux jumped the gun and made it public earlier which seems to have led to this flurry of information. If true maybe they did not do an NDA on Linux?
Stuart
I’d be surprised if the Linux community had been allowed access unless any NDAs imposed on other players could also be applied to Linux. I am maybe less sure how an NDA could be enforced however in the world of Linux, but that might just be my lack of understanding.
Here is a write up does suggest it was not due to be publicised until 9 Jan.
http://www.tomshardware.co.uk/meltdown-spectre-exploits-intel-amd-arm-nvidia,news-57627.html
As far as I can see it seems to have been first published in The Register, which also seems to be source of the, perhaps exagerated, claim of a 30% performance hit. The Register also seems to be the origin of the, possibly unfair, singular focus on Intel.
I wonder then, did somebody deliberately spill the beans, or some of them, prematurely to The Register? And if so who, and with what motive?
-
Apparently you won't get the patch from microsoft unless your anti virus program as issued a certain registration key. MS have a list of compliant AV's.
I'm using avast and so far they claim its compatable. But some people are having problems getting the update from them (others are getting the update but still not got the patch from windows updater). I think the problem from Avast is they are pushing the update out as a micro-update, so some peoples program isnt updating properly.
-
I’m not entirely convinced that tool relates to the topic of this thread.
Correct, this tool relates to a completely different issue which is a vulnerability in Intel's Management Engine (IME) software. Typically it is the later versions which have the issue which is why older CPU setups may pass and more recent ones may fail. This is the Intel link (https://security-center.intel.com/advisory.aspx?intelid=intel-sa-00086&languageid=en-fr) which explains the potential problem and what to do about it. In Windows it is easy to check if IME is installed, and if so what version through Control Panel->Progams and Features->Intel Management Engine Components.
I have incidentally received the patch for Windows 10 64 as an update entitled January 3, 2018—KB4056892 (OS Build 16299.192).
-
I’d be surprised if the Linux community had been allowed access unless any NDAs imposed on other players could also be applied to Linux. I am maybe less sure how an NDA could be enforced however in the world of Linux, but that might just be my lack of understanding.
It was not an NDA in the true sense; it was an embargo which allowed vendors enough time to come up with the necessary mitigation.
Someone told me that *BSD devs cannot be held to NDAs and the like (due to the way it is licensed) which is why they were one of the last to know about this.
https://www.freebsd.org/news/newsflash.html#event20180104:01 (from: https://github.com/hannob/meltdownspectre-patches)
It's possible that the likes of Google, MS, Apple, Citrix and the like have known about this for many months.
The really weird thing is that Theo de Raadt pointed this out over 10 years ago!
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
-
It does appear that there is a lot of hype about this and many rumours, Ive been trying to do a bit of digging.
Reliable information can be found from spectreattack.com (https://spectreattack.com/). Anything on there is practically straight from the horses mouth. From there there's several [official] white papers by academics & universities etc.
From what I can gather there are two main vulnerabilities - both of which use side channels to obtain information from the accessed memory location.
- Meltdown. Seems to affect only certain Intel CPU's
- Spectre. Affects practically every system Intel, AMD and ARM.
- Both vulnerabilities have been there for years (10+).
- Both vulnerabilities have only recently been discovered. Cant find a time frame but indications are a number of months. The white papers are undated
- Spectre appears to be particularly problematic and not so easy to fix.
- It is true that the likes of Intel, AMD, ARM and many other academics have been working on a fix under some sort of NDA/embargo
- Certain organisations such as Microsoft, Apple, Google & various Linux bods were informed and also working to find a solution
It would appear that someone leaked and The Register published early. Whether they should have or not is up for debate, because this seems to have caused a panic situation before an official announcement.
TBH I don't think they should have. Yes its given then a lot of publicity, but apparently they are also the source of the unsubstantiated 30% decrease in performance and further panic.
Christ-on-a-bike. This type of incident is one of the few where it is not in the public's best interest to release information when a fix is supposedly being investigated. This has been bubbling under the surface for circa 10yrs, but now its public knowledge of course certain sectors will try exploit it... and hence why the main operating systems are pushing out their own updates ahead of time. In reality this really needs fixing at the hardware layer.. not the O/S.
So perhaps not quite as sinister as first appears. Yes there may have been some smoke-screening.. but Intel are not wrong when they said they have been working with AMD etc etc because Spectre does affect those other processors too.
-
Regarding timeframes, I’ve seen several respectable sources quoting Google as saying they informed others about it in June/July last year.
https://www.theguardian.com/technology/2018/jan/04/meltdown-spectre-worst-cpu-bugs-ever-found-affect-computers-intel-processors-security-flaw
Google said it informed the affected companies about the Spectre flaw on 1 June 2017 and later reported the Meltdown flaw before 28 July 2017. Both Intel and Google said they were planning to release details of the flaws on 9 January, when they said more fixes would be available, but that their hand had been forced after early reports led to Intel stock falling by 3.4% on Wednesday.
Everybody concerned seems to have been well prepared, with carefully coordinated statements ready for publication on 9th Jan. No panic, just a coordinated response, showing the whole industry working well together. Unfortunately, that seems to have been scuppered by early reporting, making things look worse than they were.
I do hope the motive for early release does not turn out to be profiteering from the movement in Intel’s share price. But I would imagine that is something the US financial regulators might be looking in to. :-X
-
I agree with Kitz about how it should be fixed in hardware, but not only if it doesn't kill performance which is very hard-won and increasingly in short supply. Processors aren't making the strides they used to in terms of straight clock speed and cycle count performance. Multi-instruction parallelism isn't going to extend much beyond the four to six instructions that Intel has often been able to achieve as some code just cannot be rearranged to support instruction-level parallelism easily or at all. I was trying for ages to speed up the machine code (AMD64 code) for a few of very intensive small routines, among them one to do execute the PEXT instruction in software, one to do Bresenham’s straight line algorithm, and I simply couldn't find any way to get more parallelism - even if a Haswell or Skylake or whatever could handle more ILP, it isn't there to be exploited.
It might be that it is not too hard to modify processors to disrupt the attacks and make them impractical.
Kitz is absolutely right about hardware in another respect too though. It's not just operating systems that will need software changes if processors remain unfixed and security is a real practical issue (that is if you are unwise enough to allow evil code into your world at all in the first place). Web browsers are mentioned as a target for software mitigations in the Spectre paper Kitz references. There might be other classes of software that also need to be scrutinised, and fixing an o/s while ignoring other bits of software such as your web browser or <who_knows_what> app isn't good enough, you can't say that the job is done.
It's amusing to note that the researchers in the Spectre paper made monkeys out of the Chrome Javascript engine’s designers who thought they had put in a ‘security’ hack by intentionally mucking up the quality of the results from a high res timer routine in order to supposedly frustrate would be malefactors but the researchers simply bypassed this and made it irrelevant by writing their own high-res timer routine. Total stupidity just making life more difficult for the vast majority who are non-malicious and now the bad guys know exactly what to do to get ultra-high-res timing anyway. When will these people learn?
-
I do hope the motive for early release does not turn out to be profiteering from the movement in Intel’s share price. But I would imagine that is something the US financial regulators might be looking in to. :-X
So who would gain? Thats what's puzzling me.
The El reg release seemed to completely gloss over Spectre, which by all accounts is the larger and more difficult problem.
Obviously the CEO or whoever of Intel selling a large portion of his shares prior to the muck hitting the fan looks suspicious, but then again it doesnt take a genius to work out that there's a good chance the value of Intel would take a dive the way it was released.
Why did El reg publish when others were keeping stum ahead of the scheduled release date. It was also El reg that released the 30% slow down figures, yet now patches have been released and its undeniable that some processors have taken a performance hit, it does not appear to be anything like the 30% headline figure quoted.
Has that article been amended?
Publication of article is 2 Jan 2018 at 19:29 GMT.. yet the linked to reference is 11:58 PM - Jan 2, 2018 UTC ???
It does say at the end final update and that their report was on Meltdown and not Spectre.
-
based on this el reg seems to have overhyped it somewhat.
https://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked.html
-
So who would gain? Thats what's puzzling me.
From my limited understanding, simple short selling, surely?
https://www.investopedia.com/terms/s/shortselling.asp
My understanding is that any trading based on inside knowledge is illegal and short selling coincident with big news events like this, would automatically attract attention from regulators. But if the traders turn out to be beyond US jurisdiction, not sure what they’d be able to do.
-
based on this el reg seems to have overhyped it somewhat.
https://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked.html
I suspect we will see more like this.
El reg is a good read, always entertaining, but I long since ceased to regard it as a source of facts.
-
I see AVM have a security list for these exploits. To compromise a Modem/Router, the attacker will have to have physical access to the hardware.
https://en.avm.de/service/current-security-notifications/
-
@sevenlayermuddle - I was of the opinion that in the UK at least it's basically fairly difficult to be an 'inside trader', you have to have privileged information from the company itself and have to be an employee or someone who is conspiracy with one such. Info about CPU microarchitectures in this case was all publicly available, as members of the general public, not employees of say Intel, were the ones who did that research. So having an opinion that a cpu design is rubbish and therefore it might be a good idea to sell your shares can't be illegal, because anyone out there could come to the same opinion given a sufficiently large supply of clue, not secret information. But then I am no lawyer nor an american so what on earth do I know.
Mind you, if you worked for say el reg and wrote up an article that was contained a certain quantity of bull, like numbers of 30% say, and then went off to do some short selling of say intel stock then there might be trouble, but I'm not at all sure on what legal grounds, although it is clearly unethical market manipulation.
-
I suspect we will see more like this.
El reg is a good read, always entertaining, but I long since ceased to regard it as a source of facts.
Pretty much cane be said for almost all the press sadly :(
sensationalism over accuracy.
-
El reg is a good read, always entertaining, but I long since ceased to regard it as a source of facts.
I regard its output in the same way as that published in the satirical magazine Private Eye.
-
For a Linux kernel orientated view there is the Wikipedia entry, Kernel Page-Table Isolation (https://en.wikipedia.org/wiki/Kernel_page-table_isolation), currently with twenty nine references.
-
I agree with Kitz about how it should be fixed in hardware, but not only if it doesn't kill performance which is very hard-won and increasingly in short supply.
Just noticed the last bit. Going back to something I said earlier in the Class action thread (http://forum.kitz.co.uk/index.php/topic,20802.msg361960.html#msg361960), if they didn't apply a patch then it would be negligence.
Whilst the bug may have been there 10+ years, now that it has been discovered and made public then some sort of fix has to be applied to protect the public. Since the news broke, you can bet your bottom dollar that script kiddies around the globe are now dabbling with code in an attempt to exploit this.
Due to the nature of Meltdown, the exploit is capable of reading passwords or any other stored information on the PC and because of the way it attacks its unlikely to be detected as malware by AVs.
I don't think anyone is going to be impressed at taking a hit in performance, but the alternative of taking no action is just far too risky.
Until (if) Intel come up with a fix at the hardware level, then I guess there is no alternative but for the likes of Miscrosoft/Apple/Linux etc to put an end to the way the OS shares memory between programs and the kernel :(
-
I regard its output in the same was as that published in the satirical magazine Private Eye.
Private Eye has a good reputation for uncovering things that TPTB would like hidden. They do sometimes get it expensively wrong.
I admit that El Reg is sensationalist, but informative.
-
From the MS Script I ran here are the results for my MSI P35 Neo F V1 motherboard with Core 2 Duo E8400 CPU.
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]
Suggested actions
* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.
BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False
So from these results I gather I also need a BIOS update for the motherboard as the MS Windows patch is not enough to protect against meltdown on its own. My board is from 2008 and I have contacted MSI but as for them updating the BIOS/Microcode I shall have to wait and see although doubt it very much.
-
From the MS Script I ran here are the results for my MSI P35 Neo F V1 motherboard with Core 2 Duo E8400 CPU.
What MS Script is that? Is there a link please?
-
Just to clarify, as I think what I wrote was ambiguous- I agree 100% with kitz, I meant to say not "do nothing" but "make it configurable". :-)
-
What MS Script is that? Is there a link please?
Couldn't find the link to the MS page but the below link has all the info. Mind you getting the script to run is a minefield on its own as you might have to set execution policy to remotesigned for it to run in admin powershell.
https://betanews.com/2018/01/05/microsoft-powershell-meltdown-spectre-script/
-
yeah if you set remotesigned to run it then disable again after
-
What MS Script is that? Is there a link please?
Here you go: https://www.powershellgallery.com/packages/SpeculationControl/1.0.2
-
If you don't have PowerShell/WMF 5.x, there is a downloadable version available:
https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050
-
Just tried the downloadable version but it will not run on Windows 7 SP1 Home Premium, gave errors about manifest.
Stuart
-
A useful blog posting documenting the current (as of Jan 6, 2018) Meltdown and Spectre Linux Kernel Status (http://www.kroah.com/log/blog/2018/01/06/meltdown-status/) by Greg Kroah-Hartman.
-
@Kitz was the script useful to you?
-
I didn't get any further than the error message about running scripts and unauthorised access. :/
As I know my i76700K is one of the affected... and since Windows successfully updated KB4056892 a couple of evenings ago I didn't bother messing any more :/
-
Here's what mine says after applying the Windows Update.
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]
Suggested actions
* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.
BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
So what does all that actually mean?
-
@Ronski What is the "mine" referring to in your last post?
-
It means you need a BIOS update as your cpu microcode needs updating. What CPU are you running Ronski? MSI support have told me my motherboard isn't affected (too old) not sure I believe them.
-
@Ronski What is the "mine" referring to in your last post?
It's referring to the results of running the previously mentioned script (https://betanews.com/2018/01/05/microsoft-powershell-meltdown-spectre-script/) on my main PC. Although we have 6 desktop PC's, 1 laptop and a server here at home.
@Banger Yes I see it suggests a BIOS upgrade is required, but does it mean the Windows patch is not protecting this particular PC? I really need to read up to see just what the implications are and just how vulnerable we are.
This particular PC has an ASRock Fatal1ty X99M Killer 3.1 (http://www.asrock.com/mb/Intel/Fatal1ty%20X99M%20Killer3.1/#BIOSl) motherboard with an Intel i7-5820k, and there's no recent BIOS updates so I'll have to ask them.
-
Well it seems scripts are disabled, and seeing the comments I'm non too sure about the solutions offered.
Maybe I best leave it alone! :-\ :(
-
If using Chrome https://support.google.com/chrome/answer/7623121?hl=en-GB is probably a good idea. Comes with a hit on resources, naturally.
The patch will, however, prevent rogue Spectre-abusing scripts running on a browser and plundering the memory of other sites - it isolates every site and, indeed, frame, within its own process and the Spectre exploits as far as I'm aware cannot jump out of their own process context.
Meltdown received the coverage because it is, by a mile, worse in terms of impact and easier to exploit. Spectre can be mitigated to some extent through recompilation of binaries and ensuring appropriate isolation of workloads to processes.
EDIT: Microsoft have recently implemented something similar in MS Edge and IE 11. Grab those patches.
-
Apple have also relaeased broswer (Safari) mitigations for Safari, as well December’s Meltdown mods.
https://support.apple.com/en-us/HT208394
Interestingly, they comment on performance impact...
Wrt meltdown...
Our testing with public benchmarks has shown that the changes in the December 2017 updates resulted in no measurable reduction in the performance of macOS and iOS as measured by the GeekBench 4 benchmark, or in common Web browsing benchmarks such as Speedometer, JetStream, and ARES-6.
Wrt Spectre
Our current testing indicates that the Safari mitigations have no measurable impact on the Speedometer and ARES-6 tests and an impact of less than 2.5% on the JetStream benchmark. We continue to develop and test further mitigations within the operating system for the Spectre techniques, and will release them in upcoming updates of iOS, macOS, and tvOS. watchOS is unaffected by Spectre.
-
@Ronski I found a thread last night which explained the results of the script. The second results (VA shadowing) is the Meltdown bug which Windows has patched in software and accounts for the slight slow down. The first results are for Spectre (branch target injection) and it seems to be fully patched a microcode or BIOS update is required. Most browsers have mitigation for spectre installed but as spectre is not in the wild no one really knows.
-
For those of us whose OS makes use of a Linux kernel, there is another utility available which will analyse the status of the kernel currently in use.
https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
Just go to the above location, right-click to select all and then save as spectre-meltdown-checker.sh
Set the execution bit in the file mode (chmod +x spectre-meltdown-checker.sh) and invoke the utility.
-
Thanks Banger.
Is there a site that explains in plain English what the risks are and how easy it is to be compremised?
-
Not that I have seen Ronski and I have been doing a lot of reading. There is a lot of confusion about my setup a Core 2 Duo E8400 some saying it is not affected but the script says I need a BIOS update.
What I have done so far is Windows update on Win 10 switched to firefox and implemented site isolation on firefox and chrome to stop javascript from nicking memory contents of other processes (Spectre) whereas Meltdown is protected by OS update. I think that is the most you can do at the moment until Intel comes out with something.
-
For those of us whose OS makes use of a Linux kernel... etc
Debian has patched its kernels for the Meltdown vulnerability, but hardware support is needed to protect against Spectre.
-
I suppose selectively disabling javascript might help a bit, unacceptable sometimes obviously. Or you could have another browser, one in a VM, with none of your secrets in it, so no data to steal.
Isn't there a tool to make it easier to turn of javascript in Firefox ?
Wish there were a selective-disable-js thing for Safari ios. You can turn the whole thing off globally, but even that is quite fiddly, but that's all there is. Even an easily accessible button to flick it off/on would be an improvement, but having a per-site thing or even better also a per url (with regex) thing would be great. Is there such a thing as a Safari ios “add-in API” for developers now? To build new plug-ins/add-in modules to enhance it? I have no idea if that might make it possible to do such a thing.
-
Debian has patched its kernels for the Meltdown vulnerability, but hardware support is needed to protect against Spectre.
Odd, I have never known a hardware problem that can’t be avoided by software. Especially as other software suppliers seem to have coped? :-\
-
Spectre is not totally patched in Windows without hardware microcode also from what I have read.
-
Spectre is not totally patched in Windows without hardware microcode also from what I have read.
Yes, that's my understanding too.
-
I use Firefox ESR on my main PC. Only thing I could find was this
https://support.mozilla.org/en-US/questions/1198249
-
I think we are nit picking over whether a firmware/microcode fix is a hardware change. I would say it is not, especially if there is a mechanism whereby it can be updated by end users. :)
In any case, I have not heard Apple talk about firmware updates. But they may have ways of silently sneaking in a firmware update part of an OS update, having the advantage that they know the precice hardware environment. Or perhaps, providing you know the exact hardware configuration, as Apple do, more effective mitigation can be provided in OS and Application software?
-
It's my understanding that microcode is supplied by the hardware manufacturer, and so it's not in the power of the OS or application software developers to fix the Spectre vulnerability completely. They may be able to mitigate it in various ways, but they are dependent on the CPU manufacturers for a complete fix (assuming that it's possible).
-
My understanding is that CPU firmware is published by the CPU manufacturer, but that they will only provide updates to the PC manufacturers rather directly to than end users. The PC manufactures then push it out to end users, I assume they will have some proprietary tools for installing it - similar perhaps to a BIOS update.
In the case of Apple, the OS vendor and PC manufacturer are one and the same, which may make things easier. I see no technical reason it could not be incorporated into Apple’s usual software update channel, though I do not know if that would be too complicated, or if they have actually done so, in this or any other case.
When I saw mention of hardware support being needed, I had visions of board-level chip swapping, hence my puzzled response. And my alarm too, as Apple customers are generally not meant to swap chips. I can cope with a solution that involves new firmware/microcode, which is most certainly, in my book, still ‘only software’. :)
-
Sorry if I alarmed you. :)
I referred to it as a hardware solution because it depends on the CPU manufacturer providing the necessary microcode for their devices. The way it works in the Linux world is that the CPU manufacturers make their microcode updates available to Linux distro producers, and the latter can package them in OS upgrades. The microcode isn't permanently stored in the CPU, but is loaded at boot time.
-
Sorry if I alarmed you. :)
No problem, I’m often told I’m too easily alarmed. :D
It is a worry though. I chose my current iMac because it is one of the few modern Macs that has user-upgradeable memory, in my case through a little door in the back. And that is good, but anything more than memory means dismantling the cabinet, which is not simply screwed together, it is glued all around the edge of the glass. Various online tutorials show how to cut through the glue with a kind of miniature pizza wheel, but I strongly suspect that has potential to end badly. ::)
-
yep microcode updates are done via motherboard bios updates, consumer boards older than a few years in my opinion wont get an update
not to mention even if a bios is available the vast majority of existing boards out there wont be updated
-
Operating systems can also do CPU microcode updates. Linux does, I think Windows does also.
-
Operating systems can also do CPU microcode updates. Linux does, I think Windows does also.
I’m curious to know how that works in practice.
I assume (wrongly, perhaps) that each CPU has different microcode. Even within Intel, I’d have assumed that each member of the huge family of CPUs would each have had unique microcode.
If that assumption is bad, read no further. But if it is true....
...an Engineer putting together a Linux or Microsoft update package does not ‘know’ the CPU upon which it will be installed. Does the update package then carry all microcodes for all conceivable CPUs, or is each update tailored to the user’s hardware and built on request, or does it ‘phone home’ for microcode during the install, once the CPU is known? Or something else?
-
Does the update package then carry all microcodes for all conceivable CPUs
Yes, this is how it's done. The whole lot totals a few MB. Each one is not very big.
-
I’m curious to know how that works in practice.
Instructions here will explain for the Linux Distribution that I use:
<https://pclinuxoshelp.com/index.php/CPU_Microcode (https://pclinuxoshelp.com/index.php/CPU_Microcode)>
-
Thank you EJS and MartinGoose for satisfying my curiousity. I’ll probably have forgotten all that by Thursday but for now, I feel better educated. :)
I am slightly reminded of early career in mainframes, when OS ‘patches’ could be applied by the expendient of leaving a small deck of punched cards in a card reader, attached to the system. At boot time, the card deck was loaded and applied as, literally, a small data patch, overwriting a few bytes of memory with alternative machine code instructions.
-
Interesting I didnt know the OS could do it also.
A quick google seems to show only linux based solutions tho.
-
Found this https://support.microsoft.com/ca-es/help/936357/a-microcode-reliability-update-is-available-that-improves-the-reliabil
An XP microcode reliability update released January 7 2017.
-
one of my vps providers notified me today my vps is been migrated to a new server which has the microcode updates, in 2 days time.
Interesting to see the proactive response, although I am going to run some benches before and after to compare.
-
As more information is coming to light it turns out the el reg fear mongering may not be too overhyped.
People are coming out the woodwork showing certian load examples of heavy performance hits and there is also stability issues showing up as well, intel have issued new advice to hold on applying fixes for now as they consider it now not production ready.
Linus has openly said in public he considers intel's proposed fixes in the linux kernel a joke.
For the curious I have not applied any of the fixes on my own systems, I use a layered security approach meaning skipping over these patches I am still not vulnerable and I prefer to keep the full performance of my hardware, at least for now.
-
As more information is coming to light it turns out the el reg fear mongering may not be too overhyped.
People are coming out the woodwork showing certian load examples of heavy performance hits and there is also stability issues showing up as well, intel have issued new advice to hold on applying fixes for now as they consider it now not production ready.
I know one person who applied the bios updates and immediately got 2 BSOD's.
Apparently Microsoft know why some machines are locking up and are going to introduce another patch later on to unpick the previous one. They haven't said whats causing the lockup's though.
-
on linux and bsd the patches in development are optional via a tunable they recognised forcing a crippled cpu is unacceptable
-
This little tool is made by GRC of Shields Up fame and can be found here -> https://www.grc.com/inspectre.htm
It tells you what your machine is vulnerable to in easy to read box. My machine is patched for Meltdown but not Spectre.
-
me too
-
Thats quite a nice little tool.
Same as you guys I got
System is Meltdown protected: YES
System is Spectre protected: NO!
Performance: GOOD
Then it goes on to give a nice explanation and even the option to disable Meltdown protection if you want.
You can also run it in Advanced Tech Mode. This isn't obvious, but try clicking on the little spectre icon
This 64-bit OS on Intel Processor:
OS is Meltdown aware: Yes
OS is Spectre aware: Yes
OS Meltdown data: 0x000D
OS Spectre data: 0x0084
PCID/INVPCID support: Yes / Yes
CPU microcode updated: No
CPU is meltdown vulnerable: Yes
This system's processor identification:
Intel Core i7-6700K CPU @ 4.00GHz
Documentation of Meltdown (KVA) and Spectre (branch control speculation) bit flags returned by the NtQuerySystemInformation call which, when supported by updated versions of Windows as shown above, provides detailed information about Windows' management of these vulnerabilities:
KVA (Meltdown Vulnerability) flags:
==================================
0x01 KVA_SHADOW_ENABLED
0x02 KVA_SHADOW_USER_GLOBAL
0x04 KVA_SHADOW_PCID
0x08 KVA_SHADOW_INVPCID
Branch Prediction Speculation (Spectre) flags:
==================================
0x01 BPB_ENABLED
0x02 BPB_DISABLED_SYSTEM_POLICY
0x04 BPB_DISABLED_NO_HW_SUPPORT
0x08 SPEC_CTRL_ENUMERATED
0x10 PRED_CMD_ENUMERATED
0x20 IBRS_PRESENT
0x40 STIBP_PRESENT
0x80 SMEP_PRESENT
The presence of the relatively recent PCID and INVPCID support allows Windows (when it chooses to take advantage of this) to protect against the Meltdown vulnerability without significant system performance impact.
AMD processors do not require, do not offer, and do not need the PCID and INVPCID support since they are inherently invulnerable to Meltdown attack.
"CPU microcode updated" indicates that this system is using recently updated Intel or AMD microcode which provides the control over branch prediction speculation required to allow an aware operating system to protect the system from the Spectre vulnerabilities.
This application will run under WINE and can therefore be used on non-Windows systems. Although its operating system data may not be meaningful under WINE, its display of the underlying processor capabilities will be accurate.
For more information see GRC's InSpectre web page
Copyright © 2018 by Gibson Research Corporation
Copied the full thing as it says it will run on other O/S with WINE.
-
I ran it under wine on my AMD PC running openSUSE Tumbleweed and it said I was Meltdown protected but Spectre vulnerable which is rather what I suspected anyway.
Stuart
-
I can't possibly even see any point until there is any chance of actual threat is the wild. And even then just don't let evil software run on your box. But browsers will have to be fixed tho, unless you turn javascript off everywhere, which is hard going, especially as they don't make it easy to do so selectively.
The later you leave it, the more time there will be to actually get patches sorted out properly as in some cases I feel sure that a rethink will be needed. (Thinking about what I myself would have to get up to, a high chance of don't a poor job and then a much better job second time round, which is so often a pattern with me if not others. [Once wrote an RS232 driver, subsystem and API for an o/s did a really feeble job of it and then luckily had the chance to oversee a total redesign with stunningly better results. It was about adding background-processing i/o into a completely non-multitasking o/s, so apps could do background printing and completely overlapped i/o and computation where it made sense, all without apps having to change at all. Like in DOS 2.0 iirc.])
-
Been some VPS performance issues, here is an email received.
This message is to clients on NYCSKVMS7. In our email regarding the recent Intel CPU vulnerabilities, we noted that performance issues would be a likely side effect of the patches. We have since determined that a different patched kernel may alleviate some of those problems. Due to the significant reduction in performance this node is currently experiencing, we are scheduling a reboot for tomorrow (February 7) at 8 PM eastern (GMT -5). Downtime should not be more than a few minutes. If your VPS does not reboot, please make sure you do not have a CDROM / ISO mounted in the SolusVM CP.
I got no idea what patch they originally rolled out. But it seems the performance impact was higher than anticipated.
Misformed quote corrected - Roseway
-
https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/6/
Above is a complete (subject to updates) list of CPU's affected by Meltdown and Spectre. Both my current CPUs have now appeared on the list, the Pentium Dual E2180 and Core 2 Duo E8400. No software mitigation as yet for Spectre on Windows but Meltdown has been pushed out on most Windows current platforms.
-
I'm kinda 50/50 on this in my thoughts.
Yes the security gap was there for many years and it needed to be fixed.
But on the other hand nobody in the real world actually used it, and wasn't the demonstration done on a linux system?
This all feels over hyped and rushed. I'm not sure if the fix that Microsoft was rolling out is currently being deployed. The last I heard they had to stop the rollout to at least AMD based computers because it was causing massive problems.
This as been a bad marketing disaster especially for Intel. Patch the cpu and take a performance hit. Does the performance hit become mitigated if the bios was updated? But then again, how many people will update their bios? I bet very few.
-
some technical info here by the dragonflybsd dev who says its not viable on his OS.
http://lists.dragonflybsd.org/pipermail/users/2018-January/335633.html
also here some info here https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/
Meltdown patch is effective, but adds new system calls to kernel operations, in lame speak it means userland processing has zero performance impact, but kernel processing has heavy performance impact (halving of performance). Generally in laymens terms i/o and networking overheads will double. You can see a graph posted on the arstechnica page from a admin of a server showing his cpu utilisation doubled on a patched system. The reason desktop's (on average) are seeing much lower visible performance hit's is because much more of their processing is userland, but its not entirely userland.
Spectre has 2 variants as has already been mentioned here. One can be patched in software, on Windows I believe the patch will only be applied if a certian registry key exists to indicate a/v software is compatible, otherwise the patch wont be installed. The second patch requires a updated cpu microcode. The spectre patch effectiveness and performance implications are noted in the first link I posted. Basically there is a choice between hardening spectre mitigation just on kernel calls (so limited impact on most desktops but still heavy on servers), or hardening on all cpu instructions (massive performance hit to everything). Microsoft has done the former else there would be meltdown on the internet about performance, but its noted that the former will allow things like browser exploits to still work. The latter is also not even a complete mitigation. Also to avoid a meltdown about windows server performance, when the patch is installed its by default disabled.
On my PfSense unit I have decided to mitigate neither, it has no web browser, it has no public services, its pointless.
On my desktop at least for now I have also decided to not mitigate either, the OS is hardened, the browser is hardened and I have common sense. My laptop I will probably mitigate meltdown but not spectre.
Family members is a different story, hardening their OS and browsers is difficult as it compromises ease of use, so they get confused etc. Hardening gets undone on automated Windows 10 feature updates, and they dont have the IT savvyness to know what sort of things to avoid doing that puts them at risk, so I will make sure they mitigated as much as possible.
Thats my current take on it, for home equipment, servers is a different story.
Much of intel's IPC improvements in the past decade or so have come from branch prediction, full spectre mitigation disabling all of that sets CPU's back a decade or so in performance hence the heavy performance hit.