From mboxrd@z Thu Jan  1 00:00:00 1970
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  3 Jan 2018 08:43:58 -0500 (EST)
Subject: [TUHS] OT: critical Intel design flaw
Message-ID: <20180103134358.3F16818C098@mercury.lcs.mit.edu>

    > From: Andy Kosela

    > it appears this is a fundamental Intel bug that exists in all x86_64
    > CPUs.

I'm highly amused by the irony. Intel throws bazillions of transistors at
these hyper-complex CPUs in an attempt to make them as fast as possible - and
(probably because of the complexity) missed a bug, the fix for which
involves... slowing things way down!

I wonder how many other bugs are lurking in these hyper-complex designs?
Didn't anyone at Intel stop to think that complexity is bad, in and of itself?
But I guess the market demands for faster and faster machines outweighed that
- until it bit them in the posterior. The real question is 'how many more times
will it have to happen before they get a clue'?


There's an interesting parallel between this, and uSloth's struggle with
security and bugs. For a long time, it seemed it was more important to the
market to add features (i.e.  complexity), and security be damned - until poor
security really started to become an issue.

So now they're trying to catch up - but seemingly still haven't got there, in
terms of the fundamental architecture of the OS, as the never-ending stream of
bug patches attests.

The sad thing is that how to provide good security (not perfect, but much,
much better than what we have) was worked out a long time ago, and Intel hired
Roger Schell to add the necessary hardware underpinnings when they did the
386:

  http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf

Mutatis mutandis.

	Noel