X86 dispatch contention vulnerability

[jim bell]

 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 at 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 at yahoo.com> wrote:

 Sounds like a valid issue!
            Jim Bell
    On Wednesday, November 14, 2018, 9:36:06 AM PST, Ryan Carboni <ryacko at 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?  
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5476 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20181114/aa3027c9/attachment.txt>