[Simh] Fwd: VAX + Spectre

The main difference between Meltdown and the various Spectre problems was that Meltdown didn't require you to find code that runs in protected space to cause the sideband effects. Spectre required knowing about specific code running in protected mode to do the dirty work for you. You just pass some tool, with privileged execution, the location you want to probe and then watch the sideband effect. This latest one is bad for a touch typer or those that always enter the password in the same way. It looks for the timing of when you hit keys and then makes guesses on what keys would typically take that length of time to type. Most any processor running multiple users might be susceptible to this one. It does depend on the typical touch typer trained person or at least one of the typical two finger typers. It works too good to let go by as not an issue. Even dithering the processor's timer enough to avoid the other problems isn't enough to hid this one. People type to slow compared to the processors cycle time. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Clem Cole via cctalk <cctalk at classiccmp.org> Sent: Tuesday, September 17, 2019 11:01 AM To: Paul Koning <paulkoning at comcast.net> Cc: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>; SIMH <simh at trailing-edge.com> Subject: Re: [Simh] Fwd: VAX + Spectre I can simplify the question a bit. I have to be careful as I work for Intel and I've been involved with a small bit of it on our end and some of the lawyers are a bit touchy about the whole situation. So I need to add - these opinions are my own not necessarily my employers. Basically, if you have a CPU and microcode design that is post the IBM AGS that uses any type of branch prediction or speculative execution, the processor is now suspect. But you need to do the analysis originally proposed in the German paper. It helps to have the google teams work next to you when you do that analysis because you now have a recipe for how to apply the ideas, but that is not the only way to apply them. Before then, nobody had thought about the problem. While you point out the attack is carried out in the Google paper using the MMU, the attack is against the internal instruction predictor. Since the original Google paper, a number of other ways of attacks against the microcode have been reduced to practice by other teams. In the case of the Vax ISA, the original 780 and 750, I do not believe any attempt at prediction was in the microcode, but that would take someone like Bob to verify. In all cases, I was never part of the Vax CPU development, so I'm not going to be able to answer/I really don't know. But I observe that by the time of the 9000 and the 8000 series Vaxen there had been enough noise in the community, particularly by Patterson et al, in the whole RISC vs. CISC front had certainly caught the attention in the CPU designer's eyes. The techniques that were being considered were completely and fully discussed in the open literature. I certainly had read Cocke's and Russ's papers by then in grad school. I have to believe the same was true of the folks in DEC's HW team. Certainly, by Alpha time when I was around, those ideas were well-baked at DEC and I would be quite surprised if a similar attack could not be performed against EV5 and EV6. Bottom line, you need to really look at the microcode and very it. Clem ? On Tue, Sep 17, 2019 at 1:40 PM Paul Koning <paulkoning at comcast.net> wrote: