Intel CPUs Massive Security Flaw issue
-
Also they will have to try to find performance gains another way. Out of order Instruction execution and branch prediction were big deals when they were implemented. Limiting access to a page frame to the process that created it is a way that may be able to fix the issue. Reducing the access to the high resolution clock (if possible) may also be a way to mitigate these timing leak attacks. I'm not a expert though, I just stayed at a Holiday Inn Express last night.
-
Mikeisrespectful… Yeah. 32 bit got hit too.
The thing I find interesting is that researchers with nothing to gain or lose say this can't be truly fixed.
Meanwhile people who stand to lose billions upon billions are saying "We can fix it with patches".
researchers with nothing to lose have no reason to distinguish between "perfect" and "good enough". for most people "good enough" is sufficient, or else we'd all be twiddling our thumbs waiting for a "perfect" system to appear.
-
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.
-
Mikeisrespectful… Yeah. 32 bit got hit too.
The thing I find interesting is that researchers with nothing to gain or lose say this can't be truly fixed.
Meanwhile people who stand to lose billions upon billions are saying "We can fix it with patches".
researchers with nothing to lose have no reason to distinguish between "perfect" and "good enough". for most people "good enough" is sufficient, or else we'd all be twiddling our thumbs waiting for a "perfect" system to appear.
Also, you can't fix a problem that you don't know about. Apparently, Google discovered this problem last June, so Intel wouldn't have considered fixing it years ago.
-
Thats true, and totally understandable. However, downplaying the severity and lack of full fix isn't understandable.
In the end, the first company to come up with a high performance chip that isn't susceptible is going to make trillions of dollars. Hopefully it will be a new contender and an entirely new architecture. We are due for a refresh.
-
In the future, they will have to develop new hardware that doesn't have this problem.
I'd love to see the following:
- replace all the CPUs sold last "x" years free of charge (under warranty - the product is faulty, right?)
- offer massive discounts to upgrade CPUs from affected models to fixed models outside the warranty time
- offer discounts through OEM partners for CPUs embedded in motherboards, to replace CPUs and motherboards too (for cases when CPU is soldered to the board, like atoms and such)
-
- replace all the CPUs sold last "x" years free of charge (under warranty - the product is faulty, right?)
That's why Intel chose the "working as designed" lingo. They never said "yes, we have a fault here" which makes it incredibly hard to get a dime from them. Maybe if you take it to court, maybe not.
- offer massive discounts to upgrade CPUs …
- offer discounts through OEM partners for CPUs embedded in motherboards ...
First they would have to admit a problem caused by them. If they did so it would be a "hara-kiri" mission which even Intel wouldn't survive.
-
Likely there will be massive class action suits now that you mention it. Wonder when that hammer will drop?
It wouldn't take much work to prove that the people who designed and manufactured the chips are responsible for their flawed design. One would think?
Looking around the web I can see that several states are already filing suit against intel saying that by keeping the flaw secret for six months they allowed people to buy their products who likely would not have given the flaw. You can put me on that list. I'd have to be desperate for a new machine to buy one right now.
-
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. Their reputation is on the hook though. It is also standard to not mention bugs for a period of time to give patchers time to patch. Many businesses involved in doing the patch knew about this months ago.
-
Likely there will be massive class action suits now that you mention it. Wonder when that hammer will drop?
It wouldn't take much work to prove that the people who designed and manufactured the chips are responsible for their flawed design. One would think?
Looking around the web I can see that several states are already filing suit against intel saying that by keeping the flaw secret for six months they allowed people to buy their products who likely would not have given the flaw. You can put me on that list. I'd have to be desperate for a new machine to buy one right now.
You'd have to prove they knew there was a problem. This sort of thing might not be that obvious. What I'd really like to see investigated is the CEO selling off most of his stock, AFTER Intel was advised of the problem, but before it was announced to the public.
-
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.