We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare

As Linus Torvalds lets rip on Chipzilla

Analysis In the wake of The Register's report on Tuesday about the vulnerabilities affecting Intel chips, Chipzilla on Wednesday issued a press release to address the problems disclosed by Google's security researchers that afternoon.

To help put Intel's claims into context, we've annotated the text. Bold is Intel's spin.

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.

Translation: When malware steals your stuff, your Intel chip is working as designed. Also, this is why our stock price fell. Please make other stock prices fall, thank you.

By the way, here's what Linux kernel supremo Linus Torvalds had to say about this: "I think somebody inside of Intel needs to really take a long hard look at their CPUs, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

"Is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?"

What Intel described as "software analysis methods," security researchers describe thus: "Meltdown breaks all security assumptions given by the CPU’s memory isolation capabilities."

"Meltdown" is the name given to a side-channel attack on memory isolation that affects most Intel chips since 2010, as well as a few Arm cores. Intel's chips may be "operating as designed" but it is this processor design that's the issue; based on the research that has been published, the current design is inadequate and insecure.

Meltdown – on Intel CPUs and the Arm Cortex-A75 – allows normal applications to read protected kernel memory, allowing them to steal passwords and other secrets. It is easy to exploit, but easy to patch – and workarounds to kill the vulnerability are available for Windows and Linux, and are already in macOS High Sierra, for Intel parts. There are Linux kernel patches available for the Cortex-A75, which isn't even on the market yet.

There's also another security flaw named Spectre that affects, to varying degrees, Intel, AMD, and Arm. Depending on your CPU, Spectre allows normal apps to potentially steal information from other apps, the kernel, or the underlying hypervisor. Spectre is difficult to exploit, but also difficult to fully patch – and is going to be the real stinger from all of this.

You can find a summary of the Meltdown and Spectre bugs, here.

Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Translation: Look, over here! Scary words! And we deny them! And you'll forget that this is about stealing information, not tampering with it.

Funnily enough, no one said the security flaws could be used to directly alter data. Instead of talking about what these exploits don't do, let's focus on what they make possible.

On vulnerable systems, Meltdown allows user programs to read from private and sensitive kernel address spaces, including kernel-sharing sandboxes like Docker or Xen in paravirtualization mode. And when you've stolen the keys to the kingdom, such as cryptographic secrets, you'll probably find you can indeed corrupt, modify or delete data, pal.

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

Translation: Pleeeeeease, pleeeeease do not sue us for shipping faulty products or make us recall millions of chips.

Bug. Flaw. Security shortcoming. Design oversight. Blueprint blunder. Bungled architecture. It's the same difference. Security researchers, describing Meltdown, said: "On the microarchitectural level (e.g., the actual hardware implementation), there is an exploitable security problem."

The exploits described this week against processors rely on unsafe system designs. Flawed system designs, if you will. Buggy system designs.

Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Translation: We weren't the only one. And if we're going down, we're taking every last one of you with us.

Chipzilla doesn't want you to know that every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013.

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.

Translation: Just fucking leave us alone.

While Intel may be working with AMD, Arm, and other system vendors, any performance hit incurred from patching Meltdown is not an issue for these vendors. AMD isn't affected by the bug, and only the Arm Cortex-A75 is susceptible to the vulnerability.

The performance hit is due to implementing Kernel Page Table Isolation, or KPTI (previously called KAISER) to close the security hole. This pushes the kernel into a separate address space so it cannot be accessed at all by the running processes. The downside is that whenever an application needs the kernel to do something useful, such as read a file or send some network traffic, the CPU has to switch over to the kernel's virtual address space. This takes time, and doing it a lot will slow down the machine.

The KPTI overhead for the Cortex-A75 isn't known at the moment, and is estimated to be minimal. Arm may even rejig the A75 in light of these discoveries. As for Intel systems, we stated in our original report:

The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.

These figures were based on estimates from people working on the KPTI patches, and from simple benchmarks, such as asking a PostgreSQL database to select all records in a data store, and adding up all file sizes of documents on a disk. Some people have already reported noticeable degraded performance from their cloud-hosted virtual machines after applying the Meltdown patches. Some cloud vendors insist there won't be a problem.

It really boils down to – as we said, and Intel pointed out – your workload. If you just play games on your PC, you will not see a slowdown, beyond any delays caused by file loading, because the software rarely jumps to the kernel during gameplay. Your game will be mostly talking to the graphics processor.

If all you do is browse Twitter, write emails, and type away in a word processor, you probably won't notice any difference. If you do a lot of in-memory number crunching, you won't see much of an impact because again the kernel isn't getting in the way. If you have PCID support enabled on your hardware and in your kernel, any performance hit should be minimized.

If you hammer the disk, the network, or use software that makes lots of system calls in and out of the kernel, and you're lacking working PCID support, you will see a performance hit. And it's a good idea to warn you, right?

It's a given for this particular issue that any slowdown is dependent upon the kind of work the affected system is being asked to do. Gamers will maintain their frame rates, but that's not what this is about. It's about enterprise workloads and data centers. With reports of SQL database slowdowns of up to 20 or so per cent, it seems premature to say the impact should not be significant. If a company's AWS, Microsoft Azure, or Google Cloud bill ends up being, say, three, five or eight per cent higher as a consequence of prolonged compute times, that's significant.

No doubt the patches will be benchmarked, and we'll write about them.

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.

Translation: We were gonna say something next week, but those bastards at The Register blew the lid on it early so, uh, so, fake news! Fake news! NO PUPPET!

The preferred phrase at present is "coordinated disclosure." "Responsible disclosure" suggests the media and security researchers have been irresponsible for reporting on this issue before Intel was ready to go public. Once we get into assigning blame, that invites terms like "responsible microarchitecture design" or "responsible sales of processors known to contain vulnerabilities" or "responsible handling of security disclosures made last June."

Also, it's not clear which media reports are inaccurate, since Intel is not addressing anyone specifically.

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.

Translation: Don't click on any bad links or emails, you rubes.

Thanks for that. And remember to lock your doors at night.

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.

Translation: Who else are you gonna buy this stuff from?

One step below security by obscurity, there's security by belief. Demand more. ®

Sponsored: Minds Mastering Machines - Call for papers now open

Biting the hand that feeds IT © 1998–2018