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.
   [1]https://www.pcworld.com/article/246617/storage/evolution-of-the-soli
   d-state-drive.html
   [2]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 <[3]jdb10987@yahoo.com>
   wrote:

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

References

   1. https://www.pcworld.com/article/246617/storage/evolution-of-the-solid-state-drive.html
   2. http://www.ryli.net/the-brief-history-of-solid-state-drive-ssd/
   3. mailto:jdb10987@yahoo.com
   4. mailto:ryacko@gmail.com