Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

Post reply on HN
Print view View original

501–510 of 567 posts

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#501

Post by ufo »

rbanffy wrote: post #463
dijit wrote: post #454

Earlier quoted context omitted.

I have a power dependent workload that scales horizontally and is currently already dominated by the cost of system calls. This will effectively, directly cause me to buy 30% more compute on a huge infrastructure. (2,000~physical machines. Quite beefy dual socket machines with a lot of memory) I know I’m not alone. Then again. Think of microservices, Kubernetes for instance; Network requests are system calls.

If your workload has no code that's untrusted, you can safely skip this patch or disable it on boot. If not, at 2000+ physical machines, it may be worth to move some of that into kernel modules that would collapse a couple syscalls into a single higher level one.

The VM host will still have the patch applied, won't it?

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#502

Post by KingMachiavelli »

rogerthis wrote: post #496
rbanffy wrote: post #463

Earlier quoted context omitted.

If your workload has no code that's untrusted, you can safely skip this patch or disable it on boot. If not, at 2000+ physical machines, it may be worth to move some of that into kernel modules that would collapse a couple syscalls into a single higher level one.

But then you have to release the module as GPL, no?

No kernel modules can be closed source; GPU drivers are a common example of a closed source kernel module.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#503

Post by perseusprime11 »

What is more interesting to me is the news that came before this: Intel CEO selling his stock. I did not read the news but I got a notification on the phone through one of the many news apps on my phone. For a moment, I wondered why he sold off his stock.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#504

Post by myrandomcomment »

maxander wrote: post #483
dijit wrote: post #454

Earlier quoted context omitted.

I have a power dependent workload that scales horizontally and is currently already dominated by the cost of system calls. This will effectively, directly cause me to buy 30% more compute on a huge infrastructure. (2,000~physical machines. Quite beefy dual socket machines with a lot of memory) I know I’m not alone. Then again. Think of microservices, Kubernetes for instance; Network requests are system calls.

Will you be buying Intel-based machines? Or will you be running a hybrid-architecture cluster now? I don’t know very much about computing on that scale, but I wonder if all the people selling off Intel stock are thinking this story through.

So for what it is worth my company has all Intel kit. We run servers that run docker. In each docker container we do build / test for our product. That is all we use them for. 1RU with 2 blades, each blade is dual socket, 72 total cores, 512GB RAM. We will not apply this patch as none of this is public facing and we do not want the hit to build / test throughput. The one big thing that this has done is we were looking at AMD for new servers and that has now become a higher priority on the to do list. Given our environment we care about the number of containers we can run, period.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#505

Post by adrianratnapala »

rbanffy wrote: post #270
dsign wrote: post #19

This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…

It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…

One of the rationales for cloud computing is it saves money by cracking up utilisation. Providers observe how much users "really" use and then provisioning that much.

True, sometimes you will leave boxes at low utilisation for various reasons, e.g. to deal with traffic spikes. But those reasons have not gone away. So now instead of heaving a predictable increase in CPU cost, you have an unpredictable increase in performance snafus.

The only good news is that the real performance hit will be less than 30% on many workloads. Especially once the providers start juggling and optimising.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#506

Post by [deleted] »

RobAtticus wrote: post #456
Houshalter wrote: post #444

Earlier quoted context omitted.

A CPU from 2017 is going to run your programs a hell of a lot faster than one from 2003. Even if they technically have the same clock speed. Look at benchmarks for instance: https://www.cpubenchmark.net/high_end_cpus.html

The claim wasn't "CPUs in 2017 are not faster than CPUs in 2003" or even "CPUs in 2017 are not much faster than CPUs in 2003"; the claim was that they haven't followed Moore's law since 2003, so applying it to CPU speed nowadays is inaccurate. Of course CPUs are faster now than they were 14 years ago, just not as fast as the case where Moore's law still applied to CPU speed.

[deleted]

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#507

Post by adjkant »

jabl wrote: post #411
tedunangst wrote: post #289

Earlier quoted context omitted.

Chipotle is also up 5%. All these engineers are going to need lots of burritos to eat.

You're saying that gas in the cleanroom caused the chips to behave incorrectly? Excuse me while I go and invest in a company making rubber underwear.

Someone's gotta sell Burger King sesame seeds...

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#508

Post by mastazi »

mastazi wrote: post #499

I am confused, as far as I know two different vulnerabilities have been discovered, Meltdown and Spectre; while the first one affects only Intel CPUs, the second one affects AMD and ARM as well. So how come I'm not seeing much talk around about the latter? Is it because it is harder to exploit? I didn't have a chance to read the 2 papers so I would appreciate a TL;DR. I am a SW developer working with high level langu…

Replying to myself: most of the info can be found here

* https://googleprojectzero.blogspot.com.au/2018/01/reading-pr...

* https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...

* https://meltdownattack.com/

* https://www.amd.com/en/corporate/speculative-execution

* https://newsroom.intel.com/news/intel-responds-to-security-r...

TL;DR is that mitigation for Spectre on an OS level is not very expensive in terms of performance while Meltdown mitigation, which affects only Intel, will have a performance penalty between 5% and 30%

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#509

Post by victorhooi »

johncalvinyoung wrote: post #485
rincebrain wrote: post #462

Earlier quoted context omitted.

Addendum for anyone still reading: - Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1] - Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall…

https://security.googleblog.com/2018/01/todays-cpu-vulnerabi... https://googleprojectzero.blogspot.com/2018/01/reading-privi... Seems that Google/Project Zero felt the need to go ahead and break embargo. Worth adding to the above list of news sources.

No, that's not accurate.

If you read the article you quoted:

> We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming (update: this has been published; see above).

Just from public Gooogling, I believe it may have been the Register who tried to get in on the scoop, and broke the embargo:

https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#510

Post by steve_gh »

rbanffy wrote: post #270
dsign wrote: post #19

This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…

It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…

About 10 years ago I was mentored by a guy who was an utter wizard at queuing theory, and who bugfixed a whole bunch of nasty issues in cellular telecoms hardware through his understanding of how queuing theory impacted code execution.

TL:DR - queue behaviour gets nonlinear as you approach the theoretical max load. If you are running your processors at a high load, even a small change in code throughput makes a huge difference to real world behaviour.

Post reply on HN