Intel bug incoming.

In my opinion someone should check facebook's script. I'm told few times (for block it) here on another account's.
 
Looks like the DragonFly guys have a potential mitigation for Meltdown:

https://www.dragonflydigest.com/2018/01/05/20672.html

By now you’ve probably heard of the Meltdown/Spectre attacks. (background rumors, technical note) Matthew Dillon’s put together a Meltdown mitigation in DragonFly, done in four commits.

It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs. Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.

Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.
Click to expand...
 
Personally what I'm looking for is to see if and if not why Itanium processors are not affected (spectre). In ideal world in example as shown on RPI.

Btw. here's the official statement of IBM on ppc processors: https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

I understand why Itanium processors are not affected by meltdown, but I'm not sure about spectre. From little I know it could be due to EPIC and the way vliw (very long instruction word) is executed -- there's no room for such side channel. But with the focus on all other CPUs it's a bit disturbing there is no additional information regarding this attack for Itanium processors.
 
Intel facing multiple class action suits over chip security flaw

All my machines but one use an Intel processor. It has an AMD Triple Core with 4GB RAM and I use it sometime anyway.

I hate the thought of my Thinkpads taking a big performance hit. They are totally acceptable in performance now, but could end up a pain to use.

Now I'm emotional distressed and feeling anxious... I better get in on that lawsuit. ;)
 
_martin said:
Personally what I'm looking for is to see if and if not why Itanium processors are not affected (spectre). In ideal world in example as shown on RPI.

Btw. here's the official statement of IBM on ppc processors: https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

I understand why Itanium processors are not affected by meltdown, but I'm not sure about spectre. From little I know it could be due to EPIC and the way vliw (very long instruction word) is executed -- there's no room for such side channel. But with the focus on all other CPUs it's a bit disturbing there is no additional information regarding this attack for Itanium processors.
Click to expand...

I believe for the same reason as Raspberry Pis are not: no out-of-order execution. If I understand correctly, all three exploits rely on speculative fetch/jump/execution operations which are eventually rolled back (but not their side effects—cache loads) when bounds / access checks complete.
 
On the lighter side, I think I'll be able to afford that Intel i7 very soon!

On the darker side, I've been on vacation time all week!
 
I've read somewhere that Intel knew about this 15 years ago and did nothing about it. However, I find that highly dubious. Intel's chips have gone through several redesigns over the years. If they knew about this 15 years ago, then why didn't they address it during the design phase?

I'll tell you why, because it's bogus. I believe they found out about this back in July when it was first reported to them. The next generation of CPUs will not be vulnerable to either one. Further evidence indicates that all CPUs that use branch predictors with out of order and speculative execution are vulnerable to spectre. Once again, nobody saw this coming. And now Intel is getting sued over it. Is it fair? Is it just? No, it's not, but it is going to be expensive to fix.

IANAL, but my defense would be this: Nobody saw this coming, nobody knew about it until it was reported. We are all human beings. With that said, we cannot predict the future. Security is reactionary with regards to bugs. When these designs were first implemented, these types of attacks were not conceived of.

The Meltdown bug is pointing straight at Intel. But the Spectre bug however, is going to need a rethink of the basic CPU design which is going to take longer. How long did it take for Intel to roll out new silicon when Intel was notified about the F00F bug in the Pentium, or the FPU bug, or that one in 2001, or any of the other bugs?
 
Maelstorm said:
The Meltdown bug is pointing straight at Intel.
Click to expand...
There are people who argue that the motivation to allow deficiencies in hardware security could have been to gain unfair advantage over competitors.
And the basic problem was known for decades already from the mainframe sector experience.

So I don't think a company like Intel can get away with pretending they knew nothing.
With their doing they damaged the whole industry, the whole human community.
They pressured competitors to cut at hardware security, only to be able to compete with a cheater.

Imho Intel should pay dearly for that, maybe fined to pay a few dozen billions to charities.
But I am no legalese expert. And those will determine the outcome.

For my part, I hope this damages Intel in a way that permanently lowers its market share, increasing competition and innovation.
 
Great thread guys, I really enjoy reading it!

I am not a computer scientist so for me it is hard to understand the full impact of these security holes.

Has anyone read anything about the impact on VMs?
My questions is if you could read kernel memory on Intel machines (OS on bare metal) exploiting these flaws, how about if you exploit the flaws within a VM, would one be able to read beyond what's assigned as memory address space to the VM and say one could read memory from the VM host or another VM?
 
Eric A. Borisch said:
I believe for the same reason as Raspberry Pis are not: no out-of-order execution. If I understand correctly, all three exploits rely on speculative fetch/jump/execution operations which are eventually rolled back (but not their side effects—cache loads) when bounds / access checks complete.
Click to expand...
Meltdown is abusing out-of-order execution and tries to win a race so those instructions are executed. That instruction is using one byte of read memory you don't have access to as an index to your data. By measuring your access time to all the data you can say which byte it was (addr in cache already).

There's no out-of-order execution on Itanium, it is EPIC (explicitly parallel instruction computing). There are speculative loads, there are special registers just for that.
So spectre is maybe possible. I didn't read the paper on it yet, though I don't have that deep understanding of Itanium processors (did write only handful of assembly code for this CPU) to say it is or isn't possible.
 
Taken from fragments of the holes vulnerability scandal that massively affects Intel processors, stealthy surveillance and total control?

ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen.

The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored.

Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”.
On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles all of the hardware initialization, including memory and CPU initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes this blob to firmware developers, without source.

Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).


In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware. Link for more information:

https://libreboot.org/faq.html#intel
 
tsarya said:
My questions is if you could read kernel memory on Intel machines (OS on bare metal) exploiting these flaws, how about if you exploit the flaws within a VM, would one be able to read beyond what's assigned as memory address space to the VM and say one could read memory from the VM host or another VM?
Click to expand...
Good question. With Meltdown (I have not thought through Spectre), a non-privileged user process can read all memory that is mapped, whether they have access privileges or not (albeit very slowly). Traditionally, all kernel memory remains mapped, but marked as not accessible. And traditionally (in a non-VM environment), all hardware memory is mapped in the kernel.

And therein also lies the solution to Meltdown: Don't map kernel memory in user processes; this is fundamentally what the KAISER-style patches do (I know KAISER itself is obsolete, I can't remember all the other acronyms).

Now with a hypervisor in the middle, the question is: Does the kernel that run in the hypervisor map all hardware memory (even that which is assigned to other OS instances), or does it only map all "virtual hardware" memory that is assigned to this instance? I don't know the answer, and it probably depends on which hypervisor you are using (Xen, VMware, ...). My educated guess is that it is not mapped, and here is why: the memory layout in virtualized memory is probably the same for all instances, and having multiple instances mapped would make that harder to manage. But I'm not at all sure.

And I'm sure the answer will change very quickly, in reaction to this mess. While in theory fixing the local instance OS to not have these vulnerabilities should be sufficient, probably the VM vendors will want to put another layer of defense around that at their level.
 
Can someone remove teo's post? I have don't know whether his rant is technically correct or not; it can't be completely correct, since in real-world operations computer administration requires a full-authority "backdoor" that can access everything in the hardware (in particular take over control if the installed OS is misbehaving). But it is completely off-topic in this thread. Thank you!
 
ralphbsz I do not think it is off-topic, as this topic is about Intel bugs.

There is indeed a big problem with the IME, and not for the first time.
2016 there was a severe bug discovered that caused manufacturers like HP to issue firmware updates for all their affected computers they made the last decade (!), including for long-discontinued models.
The reason was that user programs can easily take over control of the IME.
Under particular circumstances IME makes it even possible to take over control remotely, circumventing the OS working on the computer!

See this Intel security advisory, last revieved on Dec 26, 2017.
There they offer downloading a program which shows you whether your hardware is affected and needs a firmware update.

More background here, for example.
 
Thanks wattie!
Your link includes one of the first revelations how the impact on the CPU loads has been grossly downplayed by Intel.
The CPU utilization statistcs chart speaks for itself.
pasted image 0.png

This chart shows the CPU load change after application of the security updates.
As you can see, server CPU performance dropped not by the announced maximum of 30%, but down to almost 30% of the performance before the update.
 
The issue with Spectre is that a malicious program can read its own process memory. Normally, that's not an issue for regular programs because they have to be able to read their process memory in order to function. Where it becomes an issue is virtual machines. The program running under the hypervisor runs in the same process space as the hypervisor itself (same PID, memory, etc...). A program running under a VM can read memory belonging to the hypervisor. A attacker can use this information to break out of the VM, and possibly compromise the machine. So Spectre is an information leak bug which can lead to a privilege escalation depending on the specifics of the hypervisor.

This affects any code that runs in a virtual environment. A Java application running in a web browser for instance. There have been numerous security issues relating to Java in this regard. Also javascript in web browsers runs in a virtual environment. A malicious javascript program can compromise the browser's process and read passwords, crypto keys, etc....
 
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
Click to expand...

So yeah, a lot of us desktop users might not end up being bothered a lot about the new patches.

That said, I just spent an hour trying to diagnose my VPN problem because my little brain had forgotten that I need to rewrite an iptables rule after a reboot. This, because that VPS has been solid for two years and suddenly got rebooted to accommodate the new patch. (and yes, I even got a warning email) /sigh
 
You must log in or register to reply here.
Back
Top