Intel CPUs Massive Security Flaw issue
-
Massive news. Intel has been ripped a new one over this.
The moral of the story is: never trust anyone…
-
https://www.dslreports.com/shownews/Intels-MeltdownSpectre-Fix-Causes-Numerous-CPU-Headaches-141049
-
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!
-
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. -
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/
-
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.
-
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.
-
So are you saying pfsense hardware isn't a security product?
-
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/
-
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.
-
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.
-
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.”
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.