Winston
Lorenzo von Matterhorn
- Joined
- Jan 31, 2009
- Messages
- 9,561
- Reaction score
- 1,764
Denninger below speculates that one of the reasons that Intel maintains a single thread performance advantage over AMD CPUs which do not have this flaw might be due to this security jeopardizing cheat - "...their processors speculatively execute code in such a fashion that the actual access takes place before the privilege check is done. This is good for performance but horrible for security in that it apparently can be leveraged to allow the reading of anything accessible from the hypervisor -- in other words, any other client's data."
From AMD: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
Other OSes will need an update, performance hits loom
2 Jan 2018
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
A fundamental design flaw (explained below - W) in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.
Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.
Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
Are The Idiots On EC2 (and others) Ready? (EC2 is Amazon's cloud system - W)
by Karl Denninger
2 Jan 2018 07:00
As I have long maintained in the computing world unless you have physical control over a box and supervisory control over every single employee that has privileged access to said box you have no security whatsoever.
Period.
There will always be another bug. Or a "misfeature", whether it arises out of hubris, incomplete security review, hurried production or malfeasance of some sort.
There is now some evidence that exactly that sort of "you're screwed" problem has been discovered that may well be a hardware issue in at least some commonly used processors in so-called "cloud" environments.
This would, if true, allow one "client" to "jump the fence" and either access someone else's memory (in other words, a different client) or, much worse, possibly get them access to the hypervisor at which point all pretense of security on said box falls to pieces.
Please realize that any such breach is a "game over" sort of event because it allows recovery of active encryption keys and other highly-sensitive data in active use by said other customer/client. If I can get your encryption key I can pretend to be you (bad) or simply steal all your encrypted data and decode it (maybe worse!)
The pointer to some specific discussions on this point was sent to me by a reader -- and perusing through it, and where that led me, leads me to believe this is quite real and a handful of people are extremely worried -- not only about it but about keeping it real quiet.
The question is whether that's an attempt to forestall "bad guys" from using it or customers of some of the biggest cloud providers from discovering that it can impact them and fleeing.
Given where this looks like it's aimed and heading my money is on the latter.
Oh Oh
by Karl Denniger
2 Jan 2018 18:26
Hoh hoh it really is as bad as I thought.
At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs.
At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.
No, at worst it means the hole could be abused to read hypervisor data, including encryption keys from other user's workspaces, since the Hypervisor by definition must be able to map all the guest address spaces.
In other words all cloud computing environments are insecure.
What's worse it looks like the root cause of this is that Intel cheated. In other words their processors speculatively execute code in such a fashion that the actual access takes place before the privilege check is done. This is good for performance but horrible for security in that it apparently can be leveraged to allow the reading of anything accessible from the hypervisor -- in other words, any other client's data.
This is a really big deal folks. I've heard rumblings of a severe Xen problem (a common hypervisor) for a while now -- several months of relatively loud rumbling, starting with some little chirping about a year ago and change. If this is the issue and is embedded in the architecture of the CPUs involved in modern systems then any cloud-based system will be forced to use the mitigation code which will slow it down dramatically.
Incidentally "not doing that" turns a "one machine cycle for one instruction" thing into, in many cases, a couple hundred machine cycles. It's that bad and properly "fixed" via code workaround the performance bite will be taken on every system call.
The economic impact of this renders most so-called "cloud computing" arguments moot since we're talking performance hits of 30% or more for many common workloads -- especially those that make a lot of kernel calls!
You can bet the so-called "analysts" won't pay a bit of attention to this -- but they damn well should. The "correct answer" is change all the CPUs to ones without this flaw -- RIGHT NOW -- but I'm sure you can figure out how happy some CIO (or CEO, or investors) will be to hear that. The other answer is "buy 30%+ more CPUs to cover the performance deficit", which I'm sure will produce exactly the same sort of howl and should produce the same sort of hit to stock prices.
It probably won't, but it damn well should.
Then there's this -- it appears AMD's processors are not subject to this problem -- and it's been strongly hinted at by AMD that this is because they don't speculatively start execution of an instruction before determining whether it will result in a page fault. A common complaint is that AMD's chips are somewhat slower than Intel's for "equivalent" clock speed and capability (generation, etc.) Is the reason they were slower that Intel knowingly cheated and, if so, what implication does that have across the computing universe, especially in places where security is considered important like, oh, pretty-much everywhere?
------
Whereas AMD has its Infinity Fabric architecture which allows Moore's Law limits to be fought with the ability to link together multiple, smaller, higher-yield CPU dies which much more efficiently use a silicon wafer's area and which are, therefore, much cheaper to manufacture, Intel is currently stuck with their monolithic, everything on one huge, expensive, lower yield die technology. Now, they may lose the only advantage they have left for the bleeding edge, cost is no object, ultimate performance fanbois - slightly better single thread performance.
To make things even more interesting for the CPU consumer by providing even more competition for Intel, VIA (which bought the CPU manufacturer Cyrix years ago) has just announced plans to start producing their own CPUs.
Anyway, I have built all of my personal x86 PCs with AMD CPUs since day one for price/performance reasons. Recently, I watched the video below and will now avoid Intel-based systems simply out of principle. They nearly killed AMD with multiple instances of illegal behavior for which they were fined (not nearly enough):
[video=youtube;osSMJRyxG0k]https://www.youtube.com/watch?v=osSMJRyxG0k[/video]
From AMD: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
Other OSes will need an update, performance hits loom
2 Jan 2018
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
A fundamental design flaw (explained below - W) in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.
Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.
Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
Are The Idiots On EC2 (and others) Ready? (EC2 is Amazon's cloud system - W)
by Karl Denninger
2 Jan 2018 07:00
As I have long maintained in the computing world unless you have physical control over a box and supervisory control over every single employee that has privileged access to said box you have no security whatsoever.
Period.
There will always be another bug. Or a "misfeature", whether it arises out of hubris, incomplete security review, hurried production or malfeasance of some sort.
There is now some evidence that exactly that sort of "you're screwed" problem has been discovered that may well be a hardware issue in at least some commonly used processors in so-called "cloud" environments.
This would, if true, allow one "client" to "jump the fence" and either access someone else's memory (in other words, a different client) or, much worse, possibly get them access to the hypervisor at which point all pretense of security on said box falls to pieces.
Please realize that any such breach is a "game over" sort of event because it allows recovery of active encryption keys and other highly-sensitive data in active use by said other customer/client. If I can get your encryption key I can pretend to be you (bad) or simply steal all your encrypted data and decode it (maybe worse!)
The pointer to some specific discussions on this point was sent to me by a reader -- and perusing through it, and where that led me, leads me to believe this is quite real and a handful of people are extremely worried -- not only about it but about keeping it real quiet.
The question is whether that's an attempt to forestall "bad guys" from using it or customers of some of the biggest cloud providers from discovering that it can impact them and fleeing.
Given where this looks like it's aimed and heading my money is on the latter.
Oh Oh
by Karl Denniger
2 Jan 2018 18:26
Hoh hoh it really is as bad as I thought.
At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs.
At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.
No, at worst it means the hole could be abused to read hypervisor data, including encryption keys from other user's workspaces, since the Hypervisor by definition must be able to map all the guest address spaces.
In other words all cloud computing environments are insecure.
What's worse it looks like the root cause of this is that Intel cheated. In other words their processors speculatively execute code in such a fashion that the actual access takes place before the privilege check is done. This is good for performance but horrible for security in that it apparently can be leveraged to allow the reading of anything accessible from the hypervisor -- in other words, any other client's data.
This is a really big deal folks. I've heard rumblings of a severe Xen problem (a common hypervisor) for a while now -- several months of relatively loud rumbling, starting with some little chirping about a year ago and change. If this is the issue and is embedded in the architecture of the CPUs involved in modern systems then any cloud-based system will be forced to use the mitigation code which will slow it down dramatically.
Incidentally "not doing that" turns a "one machine cycle for one instruction" thing into, in many cases, a couple hundred machine cycles. It's that bad and properly "fixed" via code workaround the performance bite will be taken on every system call.
The economic impact of this renders most so-called "cloud computing" arguments moot since we're talking performance hits of 30% or more for many common workloads -- especially those that make a lot of kernel calls!
You can bet the so-called "analysts" won't pay a bit of attention to this -- but they damn well should. The "correct answer" is change all the CPUs to ones without this flaw -- RIGHT NOW -- but I'm sure you can figure out how happy some CIO (or CEO, or investors) will be to hear that. The other answer is "buy 30%+ more CPUs to cover the performance deficit", which I'm sure will produce exactly the same sort of howl and should produce the same sort of hit to stock prices.
It probably won't, but it damn well should.
Then there's this -- it appears AMD's processors are not subject to this problem -- and it's been strongly hinted at by AMD that this is because they don't speculatively start execution of an instruction before determining whether it will result in a page fault. A common complaint is that AMD's chips are somewhat slower than Intel's for "equivalent" clock speed and capability (generation, etc.) Is the reason they were slower that Intel knowingly cheated and, if so, what implication does that have across the computing universe, especially in places where security is considered important like, oh, pretty-much everywhere?
------
Whereas AMD has its Infinity Fabric architecture which allows Moore's Law limits to be fought with the ability to link together multiple, smaller, higher-yield CPU dies which much more efficiently use a silicon wafer's area and which are, therefore, much cheaper to manufacture, Intel is currently stuck with their monolithic, everything on one huge, expensive, lower yield die technology. Now, they may lose the only advantage they have left for the bleeding edge, cost is no object, ultimate performance fanbois - slightly better single thread performance.
To make things even more interesting for the CPU consumer by providing even more competition for Intel, VIA (which bought the CPU manufacturer Cyrix years ago) has just announced plans to start producing their own CPUs.
Anyway, I have built all of my personal x86 PCs with AMD CPUs since day one for price/performance reasons. Recently, I watched the video below and will now avoid Intel-based systems simply out of principle. They nearly killed AMD with multiple instances of illegal behavior for which they were fined (not nearly enough):
[video=youtube;osSMJRyxG0k]https://www.youtube.com/watch?v=osSMJRyxG0k[/video]
