4 ms·

> both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications) Does the x86 specification say "speculation will

> both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications) Does the x86 specification say "speculation will have no observable side effects on the memory subsytem"? I wasn't aware of that. In other words, Spectre/Meltdown are bad security flaws, but I don't think they're the result of cheating.

wahern 7y ago
Meltdown is absolutely cheating as it speculates through permission boundaries. I don't see how anyone could argue otherwise in good faith, especially considering that it was only Intel and IBM effected. AMD and SPARC were immune, and the extent of ARM's vulnerability was a single register, which seems like a bug, not reflective of an architectural design decision. You can't design your software to protect against Meltdown, which makes the ISA guarantees useless. Whereas Spectre-type side channels can be mitigated through software, which is what cryptographic algorithm implementations have been doing for years. There's far more room for debate regarding culpability for Spectre class attacks, though it's pretty clear that Intel deliberately pushed the envelope in ways that AMD and ARM weren't prepared to do.
- zwegner 7y ago
  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.

wahern 7y ago

Meltdown is absolutely cheating as it speculates through permission boundaries. I don't see how anyone could argue otherwise in good faith, especially considering that it was only Intel and IBM effected. AMD and SPARC were immune, and the extent of ARM's vulnerability was a single register, which seems like a bug, not reflective of an architectural design decision. You can't design your software to protect against Meltdown, which makes the ISA guarantees useless. Whereas Spectre-type side channels can be mitigated through software, which is what cryptographic algorithm implementations have been doing for years. There's far more room for debate regarding culpability for Spectre class attacks, though it's pretty clear that Intel deliberately pushed the envelope in ways that AMD and ARM weren't prepared to do.

zwegner 7y ago
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.