In "the good old days", in the 1970's, microprocessors were so much simpler. My favorite one for awhile, the Z-80 was trivial by today's standards. No multi-threading, no pipelining, no speculative instruction execution, etc. I built my own homebrew personal computer, which I called the "Bellyache I", using a Z-80. I also built a 'brick' shaped disk-emulator for it, consisting of a board with 32 sockets of stacked-8-high 2118 16-kilobit DRAM chips. (5-volt only 16 kilobit.) 512kbytes of disk emulator, which actually seemed a lot of memory at the time!!!

In about October 1981, I actually discovered an error in the documentation sheet for the Z-80: I was implementing my first "SemiDisk", and I was trying to use the INIR and OTIR instructions to do fast block-moves of data to/from the i/o mapped memory. It turned out that doing those transfers from a 128-byte block of memory had one of them "off" by 1 byte-count, and I traced the error to the fact that the Z-80 didn't operate precisely as the data-sheet indicated it should.

My company, SemiDisk Systems, was very close to the first disk emulator for a number of types of PC, including the S-100, TRS-80 Model II, IBM PC, Epson Q-10.

https://www.pcworld.com/article/246617/storage/evolution-of-the-solid-state-drive.html

http://www.ryli.net/the-brief-history-of-solid-state-drive-ssd/

Jim Bell

On Wednesday, November 14, 2018, 9:44:33 AM PST, Ryan Carboni <ryacko@gmail.com> wrote:

Pretty embarrassing for “Intel Inside” if you ask me. Wonder how many “whitehats” let their findings get suppressed for money.

On Wednesday, November 14, 2018, jim bell <jdb10987@yahoo.com> wrote:

Sounds like a valid issue!

Jim Bell

On Wednesday, November 14, 2018, 9:36:06 AM PST, Ryan Carboni <ryacko@gmail.com> wrote:

While many x86 implementation vulnerabilities in the past involve either electromagnetic emissions or cache timing attacks, I have not read anything about instruction dispatch contention. According to anger fog’s research, Intel’s implementation of the x86 instruction set does not dispatch more than three of a single instruction, and it has been so for a long time. Irregardless of their design decisions for instruction dispatch, this provides a side channel in which two cooperating processes operating on the same core can conduct half-duplex communication at the rate of 2 bits per cycle by one process attempting to compete with another process for the same capacity for dispatches over a single instruction (0, 1, 2, 3). While I do not have the resources to know how x86 processors handles dispatch contention issues, if it is handled in a regular and non-random manner, it would reach that theoretical level of severity.

This violates certain access controls assumed to be imposed by the kernel.

I suppose I can’t collect my quarter million dollar prize if I publish this to the world?