Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

541–550 of 567 posts

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

#541
post #384

Earlier quoted context omitted.

30% is a worst case for a workload optimized to hit the performance bug as hard as possible. How big it will be for your workload is a function of what your workload is. Benchmark if it is important to you.

50%, rather, is the worst case scenario. 30% is a bad case scenario, and 5% best-case scenario. Which is still a lot for large cloud providers like amazon, google, microsoft.

Any public information on how someone like Google or Facebook handle this? Do they have enough spare capacity to patch or will they need to build further capacity first? I could imagine 10% of Google's capacity (internal services, not Google Cloud) is at least a large datacentre.

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

#542

Earlier quoted context omitted.

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 Gooogli…

No-one necessarily broke the embargo. A blogger noticed unusual activity around a certain linux patchset and put two and two together, and the register mostly sourced from his article ( http://pythonsweetness.tumblr.com/post/169166980422/the-myst... )

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

#543
post #89

Earlier quoted context omitted.

From what I've read, this slowdown only affects syscalls, which, since they aren't usually a huge percentage of processing in the first place, should not have such an effect. You're more likely looking at a few percent at most, which is not going to be enough to make AMD outperform Intel. Let's stop the fear mongering and wait for actual metrics.

> From what I've read, this slowdown only affects syscalls Incorrect. It also affects interrupts and (page) faults. Any usermode to kernel and back transition.

Does that mean that you can get an instance on AWS and slowdown the underlying server for all others by forcing a lot of syscalls? Or how is performance distributed between tenants?

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

#545

Earlier quoted context omitted.

Yes. This is far worse.

I see - so this is more accessible? We're all fucked, then?

The "fear" with ME is more that governments or someone like that could spy on us... (not really a "threat" to most people in Western Countries). But still better to get rid of it. Not an imminent threat per se.

This bug is a true security bug that has been lurking around for 10 years... and it could have been already abused. This is double scary because this attack does not leave any traces behind and it allows any application to pretty much enter God Mode (this is the worst case scenario of a security situation (hence the name meltdown (like nuklear meltdown is the worst case situation in a nuclear power plant)).

This bug is also bad because in certain situations the fix of this bug causes severe peformance penatlty.

You are only fucked if you don't update your OS.

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

#546

Earlier quoted context omitted.

One does not follow the other. Where are any references to how this will let you bypass read & write? User-space applications are still interacting with a filesystem, which they access via read/write and not a block device. There's no talk in the DAX information about how this results in a zero-syscall filesystem API, and I'm not seeing how that would ever work given there would then be zero protections on anything.…

Please re-read my above comment. There is no new API. The DAX userspace API is mmap. This work is experimental but you can mmap a single file on a filesystem on this device using new DAX capabilities. Most access will not longer require a syscall. This comes with all the usual semantics and trappings of mmap plus some additional caveats as to how the filesystem / DAX / hardware is implemented. Most reads/writes will…

Please re-read mine. How is the number of syscalls (which is the only thing that matters in this context) changing if there's no API change to apps? mmap already exists and already avoids the syscall. DAX "just" makes the implementation faster, but it doesn't appear to have any impact on number of syscalls

As in, if you call read/write instead of using mmap you're still getting a syscall regardless of if DAX is supported or not. Not everything can use mmap. mmap is not a direct replacement for read/write in all scenarios.

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

#547
post #52

Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…

Reading secret data out of kernel memory is very bad on cloud environments. Keep in mind that the kernel deals with a lot of cryptography.

Sounds like reading HTTPS cert/key details from other-peoples-VM's on cloud providers wouldn't be too much of a stretch. Especially with the memory dumping demo. Combine that with something that looks for the HTTPS private key flag string and it's sounding pretty feasible. :/

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

#548

Earlier quoted context omitted.

"I'd be panic buying / selling every day to adjust which seems stressful..." Wrong way to invest. Don't buy an individual company's stock unless you are ready to (1) hold for the long-term and (2) ignore (short-term) unrealized losses. Especially in the first year after investing in an individual stock it is typical to see an unrealized loss, because gains require time to accumulate. The stock market is not a slot ma…

There's no particular reason any random company's stock should have gains over time, aside from inflation. Especially if it doesn't give dividends, you may never gain anything.

Nothing is certain, but you can sort companies into "likely to gain" and "unlikely to gain." The P/E and P/CF ratios are commonly used for this, along with other valuation metrics. The basic theory of value investing is to find companies that are likely to give you a return.

Also, historically the stock market as a whole has outpaced inflation, so even just investing in randomly chosen companies should have gains over time (there is even evidence that a portfolio of randomly chosen companies performs about the same as a portfolio of companies chosen by analysts and advisers).

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

#549

Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip running Linux (Solus) and I have no idea how I am to deal with all these CPU bugs... Any pointers?

Just sit and wait, it's all too fresh to make solid statements on this. Maybe aside from, think twice before buying Intel again.

Definitely, sadly the new AMD Ryzen's were not in laptops at the moment I needed one. To be honest, a high end ARM laptop would also have been nice, but as it is, Intel is king on >8 hrs battery life machines with decent performance.

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

#550
post #540

Earlier quoted context omitted.

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 disclo…

Not sure how this hurts Intel much, they essentially have a monopoly on the CPU space, AMD is only really competing because of their GPU unit. AMD can't scale to meet demand if there were a big shift from cloud providers. Even there Nvidia is miles ahead of everyone (GPU.) The thing is that, if anything, this could help Intel sales, because the only way to -truly- stop this is to get new chips...which Intel will provide, and vendors will have no choice for many larger clients. ARM chips have the same exploits (both variants.) AMD can't scale its business for that kind of demand, and its chips are slower...so what are you going to do?

I doubt the CEO is exactly shaking in his boots or sold for that reason. I'd even be willing to bet Intel will provide a fix on the hardware and continue to use the same sockets so cloud providers can just change them out without further hardware changes.

Intel's stock will probably trade down to 40, fill the gap and continue its uptrend, largely because the market is very bullish on the chip space right now.

Post reply on HN