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

521–530 of 567 posts

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

#521

Post by user5994461 »

mtanski wrote: post #269
panarky wrote: post #244

Earlier quoted context omitted.

How would you trade this knowledge? Intel has already dropped and AMD is up. Maybe there's more to move, but first-order effects are at least partially priced in already. But what about second-order effects? Seems like virtualization should be vulnerable (VMWare and Citrix), but maybe they actually benefit as customers add more capacity. Software-defined networking and cloud databases should also suffer though it's u…

I think the model for cloud vendors would be quite complicated. Not every version of the CPU and not every application is impacted as much (new intel processors with PCID will suffer less). Add on top of that the fact that a lot cloud customers over provision (there's good scientific papers on how much spare CPU capacity there is). Cloud service providers that sell things on a per request / real CPU usage model (vs r…

Agree on that last paragraph. The only reasonable thing people can do is buy more hardware to cover the performance loss and/or buy more hardware that's not needed using the bug as a pretext to get the budget approved now.

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

#522

Post by waz0wski »

qubex wrote: post #292

I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips…

ARM posted a good overview and affected product list today:

https://developer.arm.com/support/security-update

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

#523

Post by sitkack »

madez wrote: post #513
kabdib wrote: post #511

Earlier quoted context omitted.

Imagine that you are the person leading the team that's making an embedded system on an ARM SOC. It's not Linux, so you have your own boot code, drivers and so forth. It's not just a matter of "welp, get another kernel image." You're doing everything from the bare metal on up. (I should remark that there are good reasons for this effort. Such as: It boots in under 500ms, it's crazy efficient, doesn't use much RAM, an…

The responsibility to document the quirks and necessary workarounds lie with the manufacturer of the hardware. If the manufacturer doesn't provide the necessary documentation, then that's exactly that: insufficient documentation to use the device. There are hardware manufacturers that are better than others at being open and providing documentation. My minimal level of required support and documentation right now is…

Arm is a problem for all kernels not just Linux in how they map on chip peripherals, etc. All the problems that UEFI solve, are not solved on Arm.

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

#524

Post by astrange »

betterunix2 wrote: post #247
swarnie_ wrote: post #7

Earlier quoted context omitted.

How you hold this stock is a mystery to me. With it bouncing between $10 and $15 constantly last year it just seems far to volatile. I'd be panic buying / selling every day to adjust which seems stressful... Maybe why its a favorite of /r/wallstreetbets

"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.

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

#525

Post by rdl »

asah wrote: post #500
rdl wrote: post #412

I wonder how Intel will deal with this. If I were Intel, I'd offer free replacements for at-par performance, and potentially tiny cash payment for upgraded performance. Assuming the marginal cost to produce chips, especially older/slower ones, is very low, the only real cost to them is losing out on potential upgrade sales which would have happened organically, for a while. However, doing this keeps Qualcomm/ARM and…

rofl, you don't simply upgrade chips installed in 1+B servers and laptops and network devices and embedded systems. In fact, statistically-few devices-containing-a-CPU are designed to ever have their CPUs replaced. At the last, you replace the motherboard, which requires coordination with the vendor. Consider cars - good luck coordinating that recall!

Devices containing multiple security levels/distinct users, and where performance matters the most, are generally socketed-CPU servers. For other devices, if they're security critical and can't be addressed through software, you can upgrade them at the board or device level early. This has already happened in embedded devices due to the C2000 timer problem.

Assuming there is a software mitigation which has a performance impact, sophisticated users would be capable of adding more capacity (if it's a horizontal scale type workload), upgrading early (if they had extra capacity for futureproofing), or spending money, potentially subsidized by Intel, to upgrade immediately. If there's no mitigation, upgrade early, or rearchitect application (moving away from shared security domains on single boxes, etc.)

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

#526

Post by teekert »

marcolussetti wrote: post #165
teekert wrote: post #148

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?

The patch isn't out yet. Once it's merged in, your distribution will release patches you can install on the normal way you update your distribution.

Ah, ok, so Intel Management engine patches are also distributed in the Linux Kernel then?

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

#527

Post by pvdebbe »

dingo_bat wrote: post #337
chrisper wrote: post #180

If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.

It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.

> I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.

To me, this sounds like unnecessary work if Intel is coming up with a microcode patch within a few months.

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

#528

Post by rphlx »

dannyw wrote: post #131
tapoxi wrote: post #58

I don't know much about CPUs, so what prevents a fix via microcode update?

The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.

It's likely they could disable speculative execution in its entirety, either in ucode or UEFI, but that would harm many compute-intensive workloads by 5-10% or more, so my guess is that somebody decided to push this page table mitigation instead, taking the hit on the syscall/hypercall side as that's perceived as "less bad overall".

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

#529

Post by teraflop »

teraflop wrote: post #378
dspillett wrote: post #57

Earlier quoted context omitted.

Very little by way of details has been made public yet. Not even the technical press. Even relevant comments in the Linux source are redacted at the moment. Hopefully, further details will be released in good time (in the next month?) when people have had time to install the patches that are going out RealSoonNow (i.e. the huge plan of updates on Azure's VM hosts).

> Even relevant comments in the Linux source are redacted at the moment. People keep repeating this claim because it sounds dramatic, but I'm not sure it's a fair description. The original source appears to be a single snide tweet from @grsecurity [1] referencing this comment [2]. It's far from obvious that the comment was even "redacted" at all. It seems more likely that "stay tuned" is either a reference to the mor…

D'oh, I left out the links from this comment.

[1]: https://twitter.com/grsecurity/status/947147105684123649

[2]: https://github.com/torvalds/linux/commit/f55f0501cbf65ec41cc...

[3]: https://tglx.de/~tglx/patches-pti-184.tar.bz2

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

#530

Post by dijit »

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.

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.

Post reply on HN