Intel CPUs Massive Security Flaw issue
-
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.
-
This time is a whole lot different: the hardware mis-design causes a security hole, and this cannot be fixed, because it's hardware…
I guess you've never heard of microcode. It's the software within the CPU that enables it to understand the instruction set. Back when I used to maintain DEC VAX 11/780 computers, there were occasional microcode updates. Modern CPUs also use microcode and a recent Linux update for this problem included some microcode.
-
But this wasn't declared as a 100% fix to the issues!
-
Limiting access to high resolution timers is what google chrome and firefox have done. Also strictly segmenting memory between pages. The patch sucks to high heaven performance wise and still is vunerable.
Good enough security? Hmmmm. I don't think we will have that before a processor redesign. I mean I'm not selling my laptop or anything but I'm well aware that I need to change how I use my machines. I'm going to have to cut way back on the number of sketchy porn sites I visit.
I think they should be presenting the patches for what they are. An attempt to reduce the risk. However they consistently use language that leads people to believe the patches fix things. Last time I saw writing that misleading was when cigarette companies tried to convince everyone that smoking was perfectly harmless.
However, because of the way pfsense is used and the fact that it isn't a web browsing machine, I worry about pfsense way less than my computers that have desktops and keyboards.
No, google has also implemented per-site process segmentation as a chrome option. That makes inter-site security subject to hardware-enforced page table permissions. The hard problem is restricting memory access from a virtual machine running in the same address space as sensitive data. There are various approaches for addressing this ranging from changing the isolation model (as google did in chrome, sidestepping the problem) to adding various kinds of barriers to the userspace code (including by adding new CPU instructions). What we're talking about here is "spectre variant 1". The "meltdown variant 3" part of the announcement was basically that the guarantees provided by the page table permissions weren't being properly enforced, but that issue has been addressed. Way too many people are confused because there are multiple different vulnerabilities with a different number of different cutesy names, and those different things are being lumped together in various incorrect ways.
The "spectre variant 1" problem is the hardest and can't be magically fixed with a single patch, because there's nothing in the current design of that software to indicate to the kernel or to the hardware what code is untrusted and should be restricted from accessing memory within the process. That's why people say the problem isn't "fixed"–it can't be, until every software vendor addresses it in their own code. It isn't a fault in the hardware the way the crazies want to believe (e.g., a full replacement of basically every CPU in operation) because there was never a guarantee that code in a particular address space couldn't perform a side channel attack against data in the same address space. This basic class of attack has been known for more than 40 years, but it simply wasn't something anyone tried to address in commodity hardware & software. (Hence my comment that if we were waiting for perfect you would have had to just not use a computer for the past 40 years--which is a silly position to take, because good enough has been good enough for decades.)
-
I'm sure its not a hardware problem like everyone says. haha.
I think there is an expectation that the hardware is fundamentally secure in its design and that only software and OS issues could make it otherwise.
I'm sure the government IT guys are fairly panicked because I promise you they will not feel the patches are "good enough".
Put in other terms, if a computer was a car we would be dealing with a massive recall. -
This time is a whole lot different: the hardware mis-design causes a security hole, and this cannot be fixed, because it's hardware…
I guess you've never heard of microcode. It's the software within the CPU that enables it to understand the instruction set. Back when I used to maintain DEC VAX 11/780 computers, there were occasional microcode updates. Modern CPUs also use microcode and a recent Linux update for this problem included some microcode.
Again, there are multiple different issues being lumped together. The meltdown/variant3 issue can't be fixed in microcode because it's an MMU problem, and the microcode patching function can only affect instruction processing. That vulnerability is addressed by adding additional code to the kernel. The intel microcode updates are mostly aimed at spectre/variant2, which can largely be addressed in software–but the software changes can also take advantage of new CPU functionality to improve protections.
-
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.
-
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. -
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.
-
Time will tell.
-
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
-
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/reloadDoesn'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/
