Ralf Mardorf <ralf.mardorf-ZCLZIpdjs0kJGwgDXS7ZQA(a)public.gmane.org> writes: The vulnerability is speculative execution in connection with memory fetch. Basically, you make a conditional indirect branch via the location you want to read out with the condition being later figured out as false. The execution is abandoned at that time, but the indirect branch has invalidated previous contents of the cache depending on the abandoned target. Now you use timing registers in connection with accesses in order to figure out just where the cache is no longer valid. Since kernel and user processes generally share the same virtual address space for efficiency reasons (though obviously not the same permissions)... Basically, I'd be surprised about exceptions.

On Sat, 13 Jan 2018 20:02:28 +0000, Will Godfrey wrote: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&… this Hi, I'm not aware of Intel's past behaviour, since I was an unsatisfied AMD user. Now with my first Intel based machine I'm still satisfied, but since a few weeks I'm uncertain. For some usage I need security, for other usage I need performance. I could separate both desires, but one link claims I could disable a patch set using "nopti" and one changelog claims I could disable a patch set using "nokasier" and that is just about meltdown, not about spectre, let alone the third nameless vulnerability ... or does Meltdown and/or Spectre cover the third thingy, too? and never will be tested, since they are discontinued or something like this ;) That is my guess, too, since they formally mentioned "For non-Intel based systems please contact your system manufacturer or microprocessor vendor (AMD, ARM, Qualcomm, etc.) for updates." To me that sounds much like an insincerely "we're all in the same boat" statement, while CPUs from other vendors might be a little bit vulnerable, too, seemingly only Intel suffers from a disaster. IOW you confirmed my worries.