3 ms·

Again, I don't see that as cheating or violating a spec (or at least any guarantee made by Intel about x86(-64) behavior that I know of). I would assume that sp

Again, I don't see that as cheating or violating a spec (or at least any guarantee made by Intel about x86(-64) behavior that I know of). I would assume that speculation can do just about anything (access protected memory, run illegal/protected instructions, etc), as long as any effects aren't committed to architectural state until the speculated path retires. The existence of side channels (timing information of subsequent memory accesses) for retrieving information from speculative execution paths is a different issue. Perhaps it was naive of the architects to assume this wouldn't have any consequences beyond improving performance, but I don't know what spec it is supposed to violate.

wahern 7y ago
What's the point of protected memory, especially when using VM extensions, and particularly with regards to SGX, if the architecture is implemented in such a way that unprivileged software can read the entire contents of memory and there's no way for software, either the kernel or the processing software, to prevent it? You can make a tortured, pedantic argument defending Intel if we disregard VM-x and SGX, that memory protection was originally intended only to prevent data corruption, not confidentiality, but at the end of the day all such an argument does is emphasize the deliberate choices Intel made to sacrifice confidentiality for performance. And those choices are all the more unforgivable considering Intel's primary motivation for taking these performance short cuts were to expand into and secure their dominance of the VM and cloud hosting market; a market predicated on the ability of their architecture having the nominal capability to ensure data confidentiality.