Intel CPUs Massive Security Flaw issue
-
If I have to trade speed for security, I choose security every time. With Intel, it used to be a win-win but, with recent news… I just don't believe it so blindly anymore. Of course AMD is not the cure to all your problems but it sure starts to seem a little better.
A system with a speed of zero is perfectly secure, and perfectly useless.
-
PPP will still be somewhat slow after this gets patched. :)
-
http://www.newsweek.com/apple-iphone-chip-vulnerability-most-disturbing-security-issue-decades-771638
-
What's more is the Intel CEO sold $24M in stock months AFTER Google advised Intel of the problem, but before it was made public.
-
https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html
-
Info for those running on ARM devices:
https://developer.arm.com/support/security-update
-
"Once these backports are available, snapshots including the fixes will only be available for pfSense 2.4.x and amd64 architecture."
Thank god my D2700 doesn't do branch prediction!
"Our Amazon Web Services and Microsoft Azure customers are safe as both providers already patched their infrastructure against these vulnerabilities."
I'm dubious that cloud servers are"Safe". Mitigated and cured are not the same thing.
-
@https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html:
The FreeBSD developers will likely wait a bit before starting the backport of these patches to both FreeBSD 11 and 10. Once these backports are available, snapshots including the fixes will only be available for pfSense 2.4.x and amd64 architecture.
Did I get that right: you will neither patch the ARM-Branch nor the 2.3.x (32bit) versions of pfSense because you think use cases prevent exploration of current security vulnerabilities?
-
Here is 1 example the AMD has 8 cores 16 threads Intel 4 core 8 threads
https://www.tomsguide.com/us/amd-ryzen-benchmarks,review-4232.html
I did not reed the post in detail but at a quick look the Intel did better with less cores , I am not trying to make Intel look better just trying to justify if switching to AMD will be worth it as you still have to buy expensive CPUs like ryzen to get good performance
Keep in mind that games are highly fast core dependant now. DirectX 12 and Vulkan games will not be nearly so fast core dependant in the future. I expect the 1800X will pull ahead in future games. In the long run, AMD CPUs will be better since they specilize at multi-tasking.
-
All benchmarks performed before the BIOS upgrades needed to patch the CPUs and the OS patches are meaningless as far as I'm concerned.
To compare apples to apples, we need to compare CPU benchmarks AFTER all the patches are installed.
-
Did I get that right: you will neither patch the ARM-Branch nor the 2.3.x (32bit) versions of pfSense because you think use cases prevent exploration of current security vulnerabilities?
ARM doesn't need variant 3 (meltdown) fix. Once fixes for variants 2 and 1 are developed we will incorporate them, if possible. There are no fixes for i386 yet, so we can't comment yet.
-
I'm dubious that cloud servers are"Safe". Mitigated and cured are not the same thing.
Safe from the vulnerabilities written about in the blog post.
-
From my understanding of the problem all x86 processors are effected but the AMD processors have the ability to turn off the branch prediction feature. It would seem to me that if some bioses can be updated to turn this feature off on Intel Processors than the problem can be minimized without the 5% performance hit. We all want speed and putting the Kernel page file and user page file in the same space was a way for them to achieve this. I don't really think it's fair to blame Intel. Security is really hard and I would say the problem is really at the OS level. OS makers are working on the fix now so I would say everyone is doing their job. I would imagine in the future Intel processors will have the ability to turn the branch prediction off which will fix this issue.
Turning off branch prediction would be a much more significant performance hit. The impact of KPTI is felt on code with a lot of system calls, and has close to zero impact on code that stays in user land. Killing branch prediction would impact everything.
It's also worth pointing out that this isn't a kernel-specific issue, and that side channel attacks can impact any program that tries to isolate untrusted code. (For example, a browser running javascript.) The kernel mitigations don't fix all of those other programs–and AMD CPUs are impacted by this just as much as Intel CPUs.
Both Intel and AMD are affect by Spectre but only Intel ( and the Arms) are effected by Meltdown.
-
There are no fixes for i386 yet, so we can't comment yet.
Well, that's in contrast to "fixes will only be available for pfSense 2.4.x and amd64 architecture".
I'm not a native in this language but "only" usually means exclusively. Correct me if I'm wrong…And who has the final decision at netgate, you or jwt (who wrote the "only" blog post)?
So much for security fixes in the 2.3.x branch ... I know, you said you cannot comment yet.
The "official" announcement of "only 2.4.x branch and amd64" still stands, doesn't it?From a security standpoint this killed the 2.3.x branch - and doing so significantly before reaching the promised lifespan.
-
Well, that's in contrast to "fixes will only be available for pfSense 2.4.x and amd64 architecture".
I'm not a native in this language but "only" usually means exclusively. Correct me if I'm wrong…You should really pay more attention to what others say. We can’t implement fixes we don’t have. We will have 64-bit fixes for pfSense 2.4.x but we don’t have anything yet for i386 and it's unclear when or if fixes will be available. You don't seem to understand the magnitude of these vulnerabilities.
And who has the final decision at netgate, you or jwt (who wrote the "only" blog post)?
How is that relevant for this discussion? What's "only" blog post?
So much for security fixes in the 2.3.x branch … I know, you said you cannot comment yet.
That's rude and unwelcome attitude. We promised to support 2.3.x branch for at least a year after 2.4 release but we cannot implement fixes we do not have.
The "official" announcement of "only 2.4.x branch and amd64" still stands, doesn't it?
I'm not sure what you're asking me.
From a security standpoint this killed the 2.3.x branch - and doing so significantly before reaching the promised lifespan.
Vulnerabilities like these and fixing of the same is the main reason why we dropped i386 support, and spent a long time announcing it. Once and if fixes for i386 are available, we will incorporate them. However, predictions like "this killed 2.3.x branch" are not welcome. You are welcome to help in finding solutions but what you're doing is not helpful.
-
@https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html:
fixes will only be available for pfSense 2.4.x and amd64 architecture.
Only means exclusively what in return means that neither ARM nor 2.3.x will ever get available fixes, otherwise it wouldn't be "only". jwt would not have written it that way if he didn't mean it.
This has nothing to do with my understanding of the magnitude of these vulnerabilities. This is about a business decision and the language to describe it.
-
The FreeBSD Devs have said that initially they are targeting patches for AMD64 (x86-64) in the next couple of weeks for FreeBSD 11.1. They have not said when 32 bit patches will be available, nor have they said when they will patch FreeBSD 10.x releases although they do mention 10.3 and 10.4 in their mailing list. The pfSense team most likely doesn't have much more information at this stage and is probably why the blog post was worded as it is. Hope that helps.
Ref: https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html
-
gsiemon is correct.
-
As far as I understood, Meltdown and Spectre only affects 64-bit CPUs. 32-bit CPUs are not affected, correct me if I'm wrong.
-
As far as I understood, Meltdown and Spectre only affects 64-bit CPUs. 32-bit CPUs are not affected, correct me if I'm wrong.
Respectfully you would be wrong. If your processor does any kind of speculative branch prediction you are in the target zone.
-
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".
-
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".
From how I understand it, it can be fixed by turning a feature off in a specific way such that you don't cause to much of a performance hit but there will be a performance hit. In the future, they will have to develop new hardware that doesn't have this problem. That could be what they mean by "truely fixed". No matter how you patch this, there will be a performance hit. It is impossible to patch this in a way that will not cause a performance hit.
-
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.