CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

Any word yet on the actual performance hit per generation/CPU? Sounds like they are very unsure of the actual effect given that I've seen 2%-30% thrown around. Makes me think it will affect different architectures differently at the very least.

 

https://www.marketwatch.com/investing/stock/intc
Intel stock price down 4% today!

 

Windows Insider Preview 17063 apparently already has the patch, and already showing at least in these common benchmarks there is very very small difference in performance. The sky isn't falling and it appears the world will go on.

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/#update2

 

It does to a degree, but it varies more by task, procedure calls, and need for kernel access.

This is why gaming isn't as affected as high performance computing.

 

https://www.hardwareluxx.de/index.p...er-sicherheitsluecke-im-prozessor-design.html

Again more benchmarks with the latest Windows Insider Build 17063 that includes the KPTI patch. While there is some change, it's so small it's not even worth really the hype that has been thrown around. If this is their first hack at a fix and the change is this tiny then I'll take it. Given time and further refinements to the overhead I highly doubt there will be any measurable change after a few more patches.

 

Makes sense, will be interesting to see when more benchmarks start rolling in.

 

Yes, let us only look at the common consumer uses and benchmarks. Never mind that other, more intense uses that are seen with the HEDT and Server markets can be effected heavily.

What that shows is that, to the consumer market, Intel is not hit hard by this, generally, leaving their crown intact there. What it doesn't show is the market where the real money is, servers, and the fact they have a 99% (or had, haven't checked numbers recently) market share that may be hit significantly. So, what is being shown is that the average consumer has little to worry about. In that, I'll agree with what you have posted. But, I am not seeing your refutation on their commercial side.

 

Wish I knew the German language. I have not heard of these sites, and why isnt there any US based sites with benchmarks yet? Just curious as to how German sites are able to bench?

 

Google translate..

Also I would standby as most people probably didn't know the fix was in the latest build as the bug is under embargo until tomorrow from what I've read. I would expect that we will be seeing a lot more benchmarks being released today and tomorrow.

 

That is a reputable German site and fairly accurate. So no reason to discount the information. They are using a publicly available windows insider ring deployment to test that has been confirmed as having the kernel fix in the build. So, the report there is on the up and up so long as the final build has similar effects on performance, which we have seen variance to the negative in public releases compared to beta builds before.

 

Fair enough I was just sharing the information that has been tested so far. It's entirely possible those types of users will see a larger performance impact, but at least for now it seems most consumer type applications and uses will not see much or any impact.

 

Here is a link for some other uses that show some hard hits: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

 

So, essentially no effect on video encoding and the other benchmarks are tools I have never even heard of before. As best I can tell from those obscure tests that were selected, it's only a measurable change with file transfer speeds and some type of compiling? Is that correct, or is there something I am missing?

 

I am sure they are obscure tests, because they are for Linux. I will just wait for some windows benchmarks to pop up.

 

Looks like it might affect large database queries too.

 

Mostly, but it goes slightly beyond that.

If you run compilers, databases, VMs, and other more enterprise style software, you take the hit. If the software is packaged to not need a kernel address or permission, which most consumer software is designed not to need, then you get little to no effect. File transfers rely on checking for permissions at times, which is why that gets some. Compiling does. Database permissions, servers, etc.

What would be nice is doing a spec benchmark suite and sisoft to compare the before and after and which areas, as well as other benches like those.

What we are missing is pi and prime benchmarks, benches needing elevated permissions to varying degrees, etc.

 

That would be terrible for Intel if that proves true.

 

That is what the SQL is about. SQL databases will be hit fairly hard.

 

I can think of some high volume applications that would be absolutely crippled by that. Gross.

 

I would guess intel has a huge stake in the government. I know Intel CPUs are widely used where I work in the servers and everyone's personal laptop. I'm curious to see the fall out from this and how it actually impacts everything. I'm also curious to know how it'll impact my own system with a 980x in it.

 

I don't know if it is accurate or not, but seems like I remember reading somewhere that most government systems are still running Windows 7 and some still use Windows XP. Is that correct? I know my employer has around 25,000 laptops, thousands of workstations and hundreds of servers still running Windows 7 Enterprise and older versions of Windows Server. They started to migrate to Windows 10 in early 2017 and decided it was not going to be worth messing with at this point.

 

So they started to migrate, and changed their mind? lol

 

With as slow as government hardware/process already is, I doubt any of them will notice.

 

I believe much of the government was mandated to go to Win 10 due to enhanced security over Win 7. I know my agency has already rolled out Win 10 for the most part. Select systems are still using Win 7 where I'm at but those are in process of migrating to Win 10. In specific cases some systems are still using Win XP. Fewer and far between, but they are still out there.

lol that's more than likely accurate.

 

Every government office I visited in past jobs was an absolute hardware train wreck. Ancient legacy hardware running software that is no longer supported and only comprehended by one person in the entire building, fancy front end hardware hacked all to hell to try to force legacy software/hardware to work right with it, IE6 (and earlier) as primary browser as late as 2012, the list goes on. I don't think I'd want to be anywhere near a full government refit if they decided to just drop Intel.

 

Yup. Sure did. When the Redmond Mafia announced some of the later changes planned for W10 Enterprise that would take absolute control away from the business licensee to decide how and when things happen they said "I don't think so... homey don't play dat." I work in the financial services industry and safeguarding personally identifiable information is at the top of the list. I cannot imagine any intelligent company being able to go along with the idea of a fleet running Windows as a service. There are too many things that need to be under the exclusive control of the licensee that Micro$loth should have absolutely zero access to or control over. All updates received by our fleet are meticulously tested prior to deployment and if they do not serve a very distinct purpose relating to security they are cast aside. None are applied carte blanche just because the Redmond Mafia says so. All systems are encrypted and run through multiple VPNs and firewalls. None have the ability to run with open internet access.

 

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

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.

 

Is the bug still valid in Windows with pagefile disabled?

 

They had to issue a statement, Intel stock dropped 3.5% today. A little damage control never hurts.

 

And, nobody really knows for sure what, if anything, such a refit might accomplish. It could be like jumping from the frying pan to the fire. As AMD's new CPU architecture gains traction it could be attractive for business due to lower pricing, but God only knows what kind of security holes exist than nobody even knows about right now. The more popular any platform becomes, the more hackable it gets because hackers and thieves don't want to waste their time finding ways of exploiting systems that represent a tiny percentage of the market. In fact, that is the only reason crApple and Linux can claim better security than Windows. It's kind of like the concept of being married to an extremely ugly woman simply because no other man would ever try to steal her from you, LOL.

 

Translation: "End consumers are going to be fine, and their voices saying nothing appears to be wrong will drown out enterprise complaints online long enough to fix this, we hope."

 

Video discussing and a graphic giving an idea of apps and kernel, but more of the same.

The stopped Vista security updates a year or two ago and XP hasn't been serviced since 2012 or 13. Those WILL NOT get an update, as support has been ended for years. Win 7 is getting it primarily because corporations forced them to extend the time of upgrades (roughly for the reasons you posted in the post after the one quoted).

https://www.thestreet.com/amp/story...hip-disaster-means-for-its-stock-and-amd.html
https://fortune.com/2018/01/03/intel-kernel-security-flaw-amd/

 

Fascinating... an entire OS redesign (across different platforms) for the purpose of making it run as it should on Intel because Intel made a mistake.

I wonder how much of an OS redesign would happen if this happened with AMD... or better yet... if this redesign will affect AMD CPU's negatively (which wouldn't be the first time).

 

Exactly. But, this, if performance shifts, will allow Intel contracts to be re-opened potentially and cancelled orders on results from test-beds until they can verify performance after the fix.

Now, generally, what is being hinted at is Google and others found a group of security exploits that effect ARM, AMD, and Intel. The one that causes the largest performance hit is Intel specific (and possibly ARM as well). So, the fixes are needed overall.

Now, as we've covered looking at released benches, regular consumers have little to worry about on performance. Corporations are looking at hits that vary according to the server's purpose. Corporations are not ones to just buy Intel if they find out the other can serve them better over the lifetime of the systems. So public opinion will only keep the stock price up until we see the effect on sales in the quarterly report in March/April time frame. But, to be hit with this at the start of the quarter is painful on server sales, as deployments are based on the test-beds that were done since June of last year, unless an Intel partner. Cloud providers already, in large part, committed to adding more AMD servers to the mix. This may influence that decision, causing larger deployment and a tightening of Epyc inventory in either Q1 or Q2 of this year, when AMD sales of Epyc were predicted to ramp.

 

I'm using that one next time I hear "you can't get a virus on a mac" type arguments.

 

Linux is currently applying the Intel fix to AMD, although that part of the security problem DOES NOT APPLY to AMD. And the hit to AMD performance has been confirmed. With Linux, there is a way to work around the problem. We do not know if that is true for M$'s solution to the problem. So, M$ AMD users may get hit and have no way to prevent the hit to performance in the above use cases where performance is hit.

 

Well, let's hope nothing happens to upset the AMD apple cart anytime soon. We need them to stay in the game, kicking butt and taking names. I honestly doubt they would survive the discovery of a serious security issue like the one with Intel that all the buzz is about right now. It would be very bad for all of us if that were to happen. Because they don't have anything that overclocks well, I don't want their stuff right now, but I don't want us to go back to where we were before. It has been very refreshing to see Intel on their toes for a change. And, if AMD releases processors that overclock as well as Intel processors do, while not dropping performance like their anemic older products, I will seriously consider them as an option. I don't care about brand, I just want what I want. AMD's role in me having something that resembles what I want in the end cannot be understated or dismissed, whether it includes their products or not.

 

https://www.cnbc.com/2018/01/03/amd...s-near-zero-risk-to-its-chips.html?yptr=yahoo
So, AMD will be releasing research later today, which is nice!

Also, if this does help on server sales, it will mean to largest margin products being picked up, which increases revenue for future development. That is great news considering the added amounts they have done over the past three quarters on R&D, in part gearing up for 7nm fabrication (there was a huge increase in spending and buying more wafers last quarter). So, we should see something on the refresh in a week or so at CES, then we will have to see when they release a 7nm chip. But, added revenue in the segment where Intel is so dominant that AMD is a fleck, although they have significantly grown share relative to where they were a year ago, is going to be a nice turning point.

 

I'm cool with that, as I think you and others mentioned earlier, it won't kill Intel and will boost AMD more if they remain mostly untouched by this.

 

Hey now, that strategy has worked pretty well in history. The Germanic tribes around the Roman era had very ugly women and maintained no real privacy. Adultery was almost never committed mainly due to lack of desire. When it was, the offender was dragged through the town and beaten. Women had pretty good standing in that community and were held in higher regard than men.

All I can say about this whole thing is that in the reviews business, we're going to have an interesting challenge trying to explain why benchmark scores are suddenly a lot lower. I'm holding my breath to see the actual performance impact.

Charles

 

Updated to add
The Intel processor flaw is real. A PhD student at the systems and network security group at Vrije Universiteit Amsterdam has developed a proof-of-concept program that exploits the Chipzilla flaw to read kernel memory from user mode:

Bingo! #kpti #intelbug pic.twitter.com/Dml9g8oywk

— brainsmoke (@brainsmoke) January 3, 2018
The Register has also seen proof-of-concept exploit code that leaks a tiny amount of kernel memory to user processes.

Finally, macOS has been patched to counter the chip design blunder since version 10.13.2, according to operating system kernel expert Alex Ionescu. And it appears 64-bit ARM Linux kernels will also get a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR. We'll be following up this week.

Update on the Register article.

 

Intel's statement is smoke and mirrors. Yes other processors and OS's are of issue but they specifically avoid mentioning AMD. This may be true of ARM or VIA etc. but they again are very vague. For the average user of a modern home computer it may not matter much but to big business this could be a travesty in the making.

Edit; https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html

 

Selling off $11 million in stocks seems pretty fishy to me! Of course I've been known to wear the tin foil hat at times.

...and this doesnt look promising

https://www.theverge.com/2018/1/3/16846840/intel-arm-processor-flaw-chipocalypse-windows-macos-linux

 

AMD CPU's don't have the flaw Intel X86 CPU's have (according to AMD) but they are also being tagged as insecure and have the PTI fix for Intel applied to them as well.

A patch is available to disable the fix on AMD CPU's, but the kernel patch hasn't been folded in to the current build.

Here's an example of the PTI fix's performance hit on "du -s" run on the patched kernel on an AMD Epyc 7601 CPU:

This is bad: performance hit from PTI on the du -s benchmark on an AMD EPYC 7601 is 49%
https://twitter.com/grsecurity/status/947439275460702208

https://grsecurity.net/~spender/epyc_pti_results1.txt
https://grsecurity.net/~spender/epyc_nopti_results1.txt

phoronix PTI fix before / after benchmarks with significant IO usage show a big hit as well:

Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

So if you are keeping up with new release updates, and have an AMD CPU, make sure to set ' nopti' to disable the fix.

Spoiler: What is "du"?

FYI - "du" is a simple UNIX / Linux "disk usage" command used often by normal users to gather file size information of a specified file - or many files in a specified (or current directory).

For example "du -s ." will add up the sizes of all the files and files in sub-directories in the current directory ( "."); a simple way to see how much disk space the current folder is using.

This information gathering is very IO intensive in that it takes a lot of small IO accesses to get the file information for every file in the folder tree, while not benefiting from high speed IO capability from transferring large data - it's all small data accesses, so "du -s ." incurs the maximum OS overhead - running into the PTI fix performance penalty constantly.

 

Nothing like applying an Intel fix for an AMD cpu...Am I the only one thinking something is really wrong with this? Also the fix was made by Intel??

 

Just got this in my Windows update...It carries a weird date and install procedure....I wonder if it has anything to do with the Bug?

I'm not doing it until I find out exactly what it is.

 

Linux Will End Up Disabling x86 PTI For AMD Processors - Update: Now Disabled
Written by Michael Larabel in Linux Kernel on 3 January 2018 at 12:45 PM EST.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

"While at the moment with the mainline Linux kernel Git tree AMD CPUs enable x86 PTI and are treated as "insecure" CPUs, the AMD patch for not setting X86_BUG_CPU_INSECURE will end up being honored.

The patch covered in the aforelinked article has not been merged through to Linus Torvalds' Git tree. Instead, as of a short time ago, is now living within the tip/tip.git tree. In there is also defaulting PAGE_TABLE_ISOLATION to on and other recent fixes around x86 Page Table Isolation (PTI) support.

But what remains to be seen is if this work will be pulled into Linux 4.15 Git or not. We're within three weeks of the executed debut of Linux 4.15.0 stable and it isn't clear if these tip changes will be requested to be pulled into Linux 4.15 or be postponed until the start of the Linux 4.16 kernel merge window, since the safe bulk of the x86 PTI work is already in Git master. Right now the branch name doesn't indicate it's in any fixes/urgent queue nor has there been any pull request yet asking Torvalds to take it into his repository: normally tip.git master is with material for linux-next.

So we'll have to see what ends up happening in the days ahead, but regardless, at least the "AMD patch" is now sitting within a known tree that will eventually flow into the mainline Linux tree whether it be 4.15 or 4.16.

Update: Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.

Kernel developer Thomas Gleixner wrote in the pull request of disabling KPTI on AMD hardware, "Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead.""

 

The timing certainly makes looks like it could be the update for the Intel bugfix Microsoft Windows Update roll-out.

The Cloud Service Azure maintenance is scheduled for massive updates Jan 9th / reboots Jan 9-10th, so that's kinda the date we expect the fix roll-out to start, but it looks like the consumer's may be the first GP's if that is the update.

 

I'm a follower on this one, not a leader lol!

Someone else can be the guinea pig

 

Never a dull moment, google now says they found a similar (same?) memory security issue last year, and says that the problem they found also affects other CPU make's:

Google Makes Disclosure About The CPU Vulnerability Affecting Intel / AMD / ARM
Written by Michael Larabel in Google on 3 January 2018 at 05:33 PM EST.

"We're finally getting actual technical details on the CPU vulnerability leading to the recent race around (K)PTI that when corrected may lead to slower performance in certain situations. Google has revealed they uncovered the issue last year and have now provided some technical bits.

Google says their Project Zero team last year discovered serious flaws in speculative execution that could lead to reading system memory where it shouldn't be authorized. Google was also able to demonstrate an attack where one VM could access the physical memory of the host machine and in turn read memory of other VMs on the same host.

Google reports that this vulnerability not only affects Intel CPUs but also AMD and ARM... Contrary to AMD saying they are not affected by this issue.

Those interested in Google's just-published technical details can find them on the Google Security Blog. Meanwhile, I'm continuing in my benchmarks around the Linux KPTI performance impact, beyond this afternoon's summary.

The issue is now being called "Meltdown and Spectre" with the bug description up at SpectreAttack.com."