Intel CPUs Massive Security Flaw issue
-
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.
