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

531–540 of 567 posts

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

#531

Post by dijit »

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.

It is overwhelmingly likely that we’ll buy more intel. Power/Watt has always been superior and AMD has to prove itself over time before we’d buy it.

Not trying to kill expectations. This decision isn’t mine alone. You know the old saying “nobody got fired for buying Cisco” that applies to Intel too.

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

#532

Post by slededit »

lttlrck wrote: post #480
RobAtticus wrote: post #456

Earlier quoted context omitted.

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.

Moore’s Law doesn’t describe CPU clock speed increases.

Dennard scaling however did deal with clock speed (indirectly via power). It has failed since about 2005.

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

#533

Post by rbanffy »

ufo wrote: post #501
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.

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

Yes, but if it's your metal, you don't need to.

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

#534

Post by ubernostrum »

mkagenius wrote: post #514
rkeene2 wrote: post #452

Earlier quoted context omitted.

There is now !

Intel CEO added - "But when you take a look at the difficulty it is to actually go and execute this exploit — you have to get access to the systems, and then access to the memory and operating system — we're fairly confident, given the checks we've done, that we haven't been able to identify an exploit yet." It seems you need root or physical access to the system as a prerequisite for the attack.

You don't need root, and you don't need physical access. For Meltdown, you only need the ability to run your own code on the target machine.

Where that gets tricky is when everyone's using cloud hosting solutions where the physical machines are abstracted away, and a given physical server may be running multiple virtual servers for different customers.

Think of it like this:

* Somewhere in a data center at a cloud provider is a physical server, wired up in a rack..

* That server runs virtualization software, allowing it to host Virtual Server 1, Virtual Server 2, and Virtual Server 3.

* Virtual Server 1 belongs to Customer A. Virtual Servers 2 and 3 belong to Customer B.

* Normally, Virtual Server 1 can't access any memory allocated to Virtual Servers 2 and 3.

* BUT: Customer A can now use Meltdown to read the entire memory of the physical server. Which includes all the memory space of Virtual Servers 2 and 3, exposing Customer B's data to Customer A.

That's the threat here.

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

#535

Post by rbanffy »

dijit wrote: post #530
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.

Good idea. But it’s a windows executable and depends quite heavily on windows specifics. (In my case anyway) 30% overhead might be inscentive to revisit the assumption we can’t rewrite it for Linux.

You still can move some functionality to a device driver or something else that runs in the NT kernel space.

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

#536

Post by rbanffy »

btilly wrote: post #473
viraptor wrote: post #439

Earlier quoted context omitted.

The CPUs in cloud environments are not maxed out in general. There will be some area like batch processing and compute-specific VMs. For other cases, there's quite a bit of overcommitting of resources. And that's before you start doing scheduling that mixed workloads on a physical host for better utilisation. Source: worked on a public cloud environment.

I agree with you on most VMs. But once you schedule mixed workloads, you want each host to be balanced so that all of its capacity is utilized evenly. Which means that if CPU use increases across the fleet, you will want new hardware with more CPU.

Either that, or you'll have to put up with some processes taking longer.

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

#537

Post by lmm »

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?

Only if you want to do something that would otherwise be a violation of copyright - e.g. distribute the module to other people (assuming it's sufficiently entangled with linux to be a derivative work therof). The GPL only licenses you to do things that you otherwise couldn't do, it doesn't restrict you from doing things that were never a violation of copyright (e.g. privately modifying your own things).

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

#538

Post by lmm »

Cyph0n wrote: post #262
cortesoft wrote: post #236

Earlier quoted context omitted.

Right, but how often that happens is workload dependent. Basically, how often is your code making syscalls.

But don't all FS accesses (e.g., write to socket, read from DB) require a syscall? In that case, basically all web applications would be affected. Or am I completely off the mark?

At least one syscall happens at some point, but performance-tuned systems already use "bulk" syscalls where a single syscall can send megabytes of data, check thousands of sockets, or map a whole file into your address space to access as if it were memory.

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

#539

Post by lmm »

_0w8t wrote: post #210
spdy wrote: post #77

Earlier quoted context omitted.

Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…

This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster. So essentially this is payback time for Intel for keeping compatibility with older code and simpler to program architecture (stricter cache coherence etc.). It is like one can only have 2 of cheap, reliable, easy-to-program.

> This implies that ARM vendors do less validation. I guess ARM is just so much simpler that good enough validation can be done faster.

More likely "good enough" is much lower because ARM users aren't finding the bugs. The workloads that find these bugs in Intel systems are: heavy compilation, heavy numeric computation, privilege escalation attackers on multi-user systems. Those use cases barely exist on ARM: who's running a compile farm on ARM, or doing scientific computation on an ARM cluster, or offering a public cloud running on ARM?

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

#540

Post by chx »

partiallypro wrote: post #489
chx wrote: post #468

Earlier quoted context omitted.

I have no idea what happens when the official security disclosure happens and the bugfixes get released. And what the SEC can prove and what they can't, I do not claim to be an authority of.

Intel and AMD were informed of the vulnerability in June. The stock is up significantly since then, if the CEO was selling for that reason you'd assume it would be much sooner after. In all likelihood this is for tax purposes. The SEC would likely never be able to prove otherwise. I also doubt the SEC even looks at it. There was heavy options volume leading into it though, which they might.

The timeline of events is ... interesting: Intel filed its quarterly report October 26 and the trades were initiated on October 30 and executed November 30. There's no doubt he knew. The big question is what lies ahead. When the patches hit, when people other than, how to say, geeks realize what's up then comes the question: does Intel stock drop? If it does, then even the company might come under fire for not disclosing a significant risk.
Post reply on HN