Slashdot Mirror

Deterministic prediction is not a problem. Simple case: predict short, relative, backward conditional jump 100% taken.

But do speculate on this guess carefully: never allow a data-derived address (non-deterministic) to modify any internal processor state until the access checks are complete (not even page tables or TLB entries, much less cache lines or MESI bits).

Prediction which tracks execution history (branch prediction tables) is far more troublesome. Execution history must be regarded as process confidential. Any leak from execution history is a possible side channel.

I recall reading in the early 1980s about the difference between concrete state and abstract state, around the time C++ started to take const seriously. A typical case study was a representation of a point on a plane, which automatically toggled between polar and Cartesian representation, depending on whichever proved most convenient for the last calculation. This makes the representation of the point inherently non-const, just for calculating on the point's value. But we justified this seeming const violation by distinguishing the abstract state (the location of the point) and the concrete state (the actual representation in memory at any given moment).

You rarely (or never) saw this kind of debate inside the functional languages, which practically by edict ban discussion of concrete state (repeat after me: in the view of the application programmer there is only the abstract state, in the view of the application programmer there is only the abstract state, ... but of course, any practical implementation was very tricksy under the hood with concrete optimization, which the application programmer was basically forbidden to understand, because interaction with the time domain is somebody else's hot, embarrassing mess.)

In the context of memory management, one can view the set of memory allocations as the abstract state, and the actual memory addresses backing those allocations as the concrete state. (This is why virtual machines are even possible.)

Distinctions between abstract and concrete state in silicon go at least as far back as the 80286.

x86 memory segmentation

The privilege check is done only when the segment register is loaded, because segment descriptors are cached in hidden parts of the segment registers.

The LOADALL Instruction by Robert Collins

The 286 LOADALL is widely known because a 15-page lntel confidential document describing its use was given to many developers.

Intel originally included LOADALL in the CPU mask for testing purposes and In Circuit Emulator (ICE) support. ... LOADALL loads all of the software-visible registers such as AX, and all of the software-invisible registers such as the segment descriptor caches.

Testing becomes horrific once a processor begins caching historical state. Intel was justifiably terrified of venturing into this strange, new territory.

Caching is inherently a form of prediction: a prediction that the last value used is worth hanging onto, in case it is soon used again. (Caching in most contexts is insanely productive, so empirically, this is an extremely good prediction.)

Processors could be designed to save any amount of their concrete process state (generally invisible, except as a side channel) at every context switch, and to then clear all branch predictors, all TLB entries, all cache lines (probably involves MESI broadcasts to other processors, also evicts cached page table translations, for when the TLB is too small).

What really makes speculative execution different is its invocation of Eternal Sunshine of the Spotless Mind and it's later miniaturization as the MIB neuralizer: leak concrete state into the process-visibl

No, it is not. There were a number of F00F bug workarounds, all implementable at OS level and with negligible (if any) performance hit.

Meltdown is nothing like it. The performance impact depends largely on the load type the CPU experiences, but it is estimated to range between 5% and 30% - which is terrible.

Yeah, it looks like access to SSM gives elevated privilages over kernal (ring 0).

http://www.rcollins.org/ddj/Jan97/Jan97.html

"this marks one of the first times that Intel released a processor with known bugs"

Every chip Intel has ever shipped has had errata. This isn't unique to Intel, of course -- every chip ever shipped has had errata. The only news here is that apparently people have found a lot of bugs in this specific chip fairly quickly. But Mac users are a demanding bunch...

http://www.amd.com/epd/desiging/tsdocs/2.erratashe /index.html lists AMD's errata sheets.
http://www.rcollins.org/Errata/ErrataSeries.html documents some Intel errata from the late 90's.
http://mysearch.intel.com/corporate/default.aspx?c ulture=en-US&q=errata&searchsubmit.x=12&searchsubm it.y=8 searching for Errata on Intel's site returns 6,520 hits (most for errors in documentation). This is to their credit -- everyone makes mistakes, and documenting them benefits everyone.
http://www.freescale.com/webapp/search/MainSERP.js p?QueryText=errata&RELEVANCE=false&showAllCategori es=false&srch=1&assetLocked=false&pageSize=5&Selec tedAsset=Product+Pages& and FreeScale has a ton of errata documentation as well.

You get the idea.

In fact, Intel introduced the 8088 in 1979, not 1978. A distinction without difference. The "QDOS" that MS bought to sell to IBM for its 8088 PC was named as an acronym for "Quick and Dirty Operating System". Which has been the design principle that MS has been stuck with ever since. At the time, I used CP/M on Z80 uPs, later ported to 6502s; CP/M-86 showed it could have been IBM's first OS. But not as quick as the MS-repackged QDOS, so it didn't matter that it also wasn't as dirty. What the alternatives lacked was Gates and his "deal of the century", not any real technical advantage. That legacy, in marketing priorities, and largely consequent product quality, has continued to define Microsoft since its beginning. Because it's been a winning formula - for Microsoft, if not for competitors, or for users.

Intel holds a trademark for the letter "i".

http://www.rcollins.org/Trademarks/

Why all these stupid names for 80x86-compatible processors.

Because a chip vendor can trademark a name but can't trademark a number. Thus the move from "386", "486", etc. to the "Pentium®" line.

Did you know? Intel applied for trademark registration for "Sexium", but the CDA forced the company to sell 686 processors as "Pentium II" instead.

Furthermore, you have the right of parody. Even if the name Aimster was chosen to reflect that it's a AIM clone, the right of parody applies. See for instance the Intel Secrets. Intel tried to sue them for infringing patent on their logo, but since you have the right to make a parady on a logo, they lost.

Here is a good place to start looking for ideas -- notice that Itanium was registered a while back...