Intel CPUs Massive Security Flaw issue

VAMike

Put in other terms, if a computer was a car we would be dealing with a massive recall.

A proper car analogy would be:

someone sells a car with remote keyless entry. the key isn't super-secure, but it's good enough given what's practical to implement.
some time later, someone comes up with a way to override the keyless entry using what's now a fairly cheap and readily available device.
the car manufacturer shrugs.

A proper house analogy would be:

someone sells a remote garage door opener. the opener isn't super-secure, but it's good enough given what's practical to implement.
some time later, someone comes up with a way to override the garage door opener using what's now a fairly cheap and readily available device.
the garage door opener manufacturer shrugs.

Those are both actual examples. In no case was there a massive recall. I don't fully understand the level of irrational hysteria around the possibility that almost every general purpose CPU in existence might be replaced in some sort of ridiculously unlikely recall.

kejianshi

The problem is you think things will be patched and fairly usable and secure.

We disagree on this point. I think it is a basic flaw that will never be adequately patched.

Time will tell. I believe (an opinion) the CPU makers will end up paying lots and lots over this.

Perhaps not going broke levels of cash but I wouldn't expect profits til the next slew of hardware is released and tested to be 100% immune.

If Intel and AMD doesn't do this, another chip maker will and that would be a disaster for the current makers.

We will know one way or another pretty soon whether people just accept this or if they start looking elsewhere for hardware.

If Intel is smart they have rooms filled with overpaid geniuses designing new hardware this very second working 24/7…. Because someone does.
I definitely won't buy the "We are the only game in town so you have to accept it" line. If they try that nonsense, they will end up extinct.

VAMike

@kejianshi:

The problem is you think things will be patched and fairly usable and secure.

We disagree on this point. I think it is a basic flaw that will never be adequately patched.

No, you will never eliminate all side channel attacks in commodity hardware with commodity OSs. Nobody would buy a commodity OS on commodity hardware subject to the performance and functionality limitations that would entail. Again, there has been research on this topic literally for decades. The question is whether the systems are resistant to anticipated attacks. (That is always the bar to acceptance, nothing new or specific to this topic.) The only thing that happened in the past year is that some specific techniques for exploiting specific instances from a class of vulnerabilities were identified. Some countermeasures for those specific techniques have been deployed. The cat and mouse game continues, as it has since cats and mice were invented. What you seem to be conflating is whether the general class of problem has been fixed (no, that's impossible with the current technology) and whether the specific techniques have been mitigated against (yes, they have). There is the caveat that a lot of 3rd party code will need a lot of fixes, and there may be bugs in some of the code already released–but there is always the possibility of bugs.

Perhaps not going broke levels of cash but I wouldn't expect profits til the next slew of hardware is released and tested to be 100% immune.

We will know one way or another pretty soon whether people just accept this or if they start looking elsewhere for hardware.

If Intel is smart they have rooms filled with overpaid geniuses designing new hardware this very second working 24/7…. Because someone does.
I definitely won't buy the "We are the only game in town so you have to accept it" line. If they try that nonsense, they will end up extinct.

There will not be any major differences in the next generation of hardware. It would require a major paradigm shift which is simply not on the horizon. There are no other hardware vendors, as every modern CPU design is subject to the same class of vulnerabilities. (Not just Intel and AMD, but also ARM, POWER, etc.) It's fundamental to the way modern CPUs work, and you can either accept the performance penalty of not utilizing modern functionality or you can come up with a radical new way to achieve equivalent performance. (That is, without caches or speculative execution or instruction pipelines or NUMA, etc.) That isn't the sort of thing that just happens because someone on the internet wants it to. Generally that kind of radical change is presaged by laboratory results that are eventually refined into something commercially viable, or by incremental changes to existing products. You don't go directly from an 8080 to a Kaby Lake with nothing in between–and there isn't any sign of that kind change making its way through the pipeline.

No offense, but it doesn't seem as though you have any particular expertise in this area--which seems pretty common for the most inflammatory rhetoric on the topic. If you want to be more specific than "I think it is a basic flaw" that can't be "fairly usable and secure", then we could try to talk at a more detailed level about what the implications of each of the three variants are. Lumping the whole mess together into a vague pile of FUD doesn't offer much insight.

kejianshi

Time will tell.

w0w

Three days ago Intel released CPU microcode updates, it's time to update your BIOSes or VMware. Even if it's stated as Linux* Processor Microcode Data File, it contains binary files with a lot of processors microcode, I can't comment if it's all updated, but Haswell is updated. I've succefully edited three different BIOSes on ASUS motherboards.

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=33932

corvey

Massive news. Intel has been ripped a new one over this.

The moral of the story is: never trust anyone…

chpalmer

https://www.dslreports.com/shownews/Intels-MeltdownSpectre-Fix-Causes-Numerous-CPU-Headaches-141049

kejianshi

I'm sure its nothing. No sense crying over spilled milk… Especially when its only 10% - 30% of your milk. Thats nothing.... You still have 70% of what you paid for after all, with good-nuff security to boot.

Most of the time anyway (Work load dependent, of course). I mean if all you do is display a static image on your monitor, you might not notice any performance hit at all (-:

(Unless your computer won't boot or keeps rebooting) - My AMD just sort of slows to a crawl and hangs eventually. Its only a problem if I need to use it though. The rest of the time its barely noticeable.

Anyway - Its "fixed"ish. Stop whining!

w0w

Will the microcode update be available to install on pfSense? There is no problem with official hardware via BIOS update, but what about others?
I know that in FreeBSD it possible via sysutils/devcpu-data but it's currently would not work on pfSense because lack of support — repo and cpuctl module missing.
There are a lot of hardware that will never get any updates from manufacturers and getting it on FreeBSD/pfSense side should be the best solution.

robi

In the releasenote of the download you just provided, this is what is instructed:

-- Microcode update instructions --
This package contains Intel microcode files in two formats:
* microcode.dat
* intel-ucode directory 

microcode.dat is in a traditional text format. It is still used in some
Linux distributions. It can be updated to the system through the old microcode
update interface which is avaialble in the kernel with
CONFIG_MICROCODE_OLD_INTERFACE=y.

To update the microcode.dat to the system, one need:
1\. Ensure the existence of /dev/cpu/microcode
2\. Write microcode.dat to the file, e.g.
  dd if=microcode.dat of=/dev/cpu/microcode bs=1M

intel-ucode dirctory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated throught the microcode reload interface.

To update the intel-ucode package to the system, one need:
1\. Ensure the existence of /sys/devices/system/cpu/microcode/reload
2\. Copy intel-ucode directory to /lib/firmware, overwrite the files in
/lib/firmware/intel-ucode/
3\. Write the reload interface to 1 to reload the microcode files, e.g.
  echo 1 > /sys/devices/system/cpu/microcode/reload

Doesn't look too complicated. Should be feasible on freebsd too.

Linux detailed steps: https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/

w0w

Actually I already did that with sysutils/devcpu-data, installed from FreeBSD repo ports and placed missing module (taken from 11.1 FreeBSD) into pfSense, but I can not make it work automagically via rc.conf.local — it does not load MCU on boot. I've used shellcmd package to run it in earlycmd. But it just experimental and I am not sure will it work when FreeBSD patch is available or will not.

Ryu945

@robi:

@Ryu945:

I don't think a 5% performance drop would be declared as defective and not work in a court though. If they can't declare it defective then Intel is off the hook. Intel would lose way to much money to be a viable company if they had to pay to replace every CPU. If the CPUs didn't work, that would be one thing but crashing a company over a 5% performance loss is something else.

It's not about the fact that you loose any percent of performance. Until now, everybody was sure that the hardware is 100% safe, only software can be the blame if it contains security holes. This time is a whole lot different: the hardware mis-design causes a security hole, and this cannot be fixed, because it's hardware… the product is defective. Software can be patched, fixed afterwards, etc, and that depends on the agreement between the software manufacturer and the customer, but hardware (specially CPUs) can't be patched. It turns out that hardware contains a defect, which can be worked around by software patching - but that requires a third party to be involved.

Certain bussinesses bought software and hardware combinations based on benchmarks and performance counts, if they are not fulfilled after the patch, who's the blame? The software, because it tried to fix a fault caused by the hardware?

Intel should either replace the faulty CPU, or pay for the software fixes to each bussiness, or pay for the bussiness quality degradation if CPU can't be changed.

It has been know for years that hardware is not 100% safe. That is why there are companies with security based products that offer more secure hardware. This would be the first time I have heard of a vulnerability in a CPU though.

kejianshi

So are you saying pfsense hardware isn't a security product?

Ryu945

@kejianshi:

So are you saying pfsense hardware isn't a security product?

I am saying that standard hardware likely has some vulnerability in it somewhere. Here is an example of a company that advertises a cell phone they custum made the hardware to try to remove these vulnerabilities. That is their claim at least.

https://www.silentcircle.com/about-us/

kejianshi

I would say those companies are actually similar to pfsense in that they use readily available consumer grade hardware and run a tightly secured OS and software.

I think any processors that are immune to spectre are immune accidentally. I really don't think anyone purposely made a CPU to be immune to these attacks, but they will soon be doing it for sure.

robi

I'd love to see some general-purpose tool to edit BIOS files and update microcode inside them. Something that would know most BIOS formats, open the BIN file, advise which binary microcode file to choose, and compile a new image from it.
Because most manufacturers won't care to release BIOS updates for motherboards older than 1-2 years.

pfSense would also want to have a nice GUI somewhere to allow us to browse for a microcode pack we can download from Intel etc. and apply it at each boot at runtime. And write in the logs whether the runtime update was successful or not.

w0w

Do not update microcode now, wait.
@https://support.lenovo.com/ee/en/solutions/len-18282:

Withdrawn Broadwell & Haswell CPU Microcode Update: Intel provides the CPU microcode updates required to address Variant 2, which manufacturers like Lenovo then incorporate into their UEFI firmware. Intel has notified manufacturers of quality issues in the initial Broadwell and Haswell microcode updates with instructions to no longer distribute the affected microcode. As such, Lenovo has withdrawn previously issued UEFI firmware containing the affected Broadwell and Haswell CPU microcode. We will issue revised UEFI firmware updates as soon as possible following Intel’s release of revised Broadwell and Haswell CPU microcode. Servers affected by this issue are noted, below, as “Earlier update X withdrawn due to a microcode quality issue.”

@robi:

I'd love to see some general-purpose tool to edit BIOS files and update microcode inside them. Something that would know most BIOS formats, open the BIN file, advise which binary microcode file to choose, and compile a new image from it.
Because most manufacturers won't care to release BIOS updates for motherboards older than 1-2 years.

pfSense would also want to have a nice GUI somewhere to allow us to browse for a microcode pack we can download from Intel etc. and apply it at each boot at runtime. And write in the logs whether the runtime update was successful or not.

It is not so simple. Every BIOS is copyrighted by AWARD, AMI and whoever else… Phoenix ;D. So you just can't edit it without buying proper license and most manufacturers use also security checks, for example I just can not flash edited BIOS into Asus motherboard with standard methods — only BIOS flashback function or hardware tools, also there are some special BIOSes like HP uses for their enterprise grade hardware.
Even not so universal tool for BIOS modding like UBU have had copyright problem with AMI.