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 <[email protected]> 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 <[email protected]> wrote: Sounds like a valid issue! Jim Bell On Wednesday, November 14, 2018, 9:36:06 AM PST, Ryan Carboni <[email protected]> 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?
