Oh Oh
The Market Ticker - Commentary on The Capital Markets
Logging in or registering will improve your experience here
Main Navigation
Sarah's Resources You Should See
Full-Text Search & Archives

Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.


The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

2018-01-02 18:26 by Karl Denninger
in Technology , 434 references Ignore this thread
Oh Oh
[Comments enabled]

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?

View with responses (opens new window)