5 ms·

I might take that bet core for core, matched node size (i.e. 14nm), run out of tmpfs or NVMe storage, and with both systems protected against Spectre, Meltdown

I might take that bet core for core, matched node size (i.e. 14nm), run out of tmpfs or NVMe storage, and with both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications)... Slightly OT, but if you limit the playing field to open ISA / fully owner controlled systems, POWER9 is so far out front in terms of performance that it looks like an outlier. ;)

Sir_Cmpwn 7y ago
A race of one is easily won :)
- tpearson-raptor 7y ago
  Well, to be fair I was thinking of the SiFive RISC-V board as one of the competitors, since my understanding was they did finally open the rest of their firmware a while back. However, yes, by far most of the remaining owner controlled systems are even smaller -- some of the smaller (older) ARM Chromebooks (sans GPU, of course), the BeagleBone black, those kinds of systems.
  - Sir_Cmpwn 7y ago
    Yeah, I also have a HiFive Unleashed which is totally open, but it doesn't really aim to compete with Raptor iiuc. Until recently it also won out on open ISA, too, and the Blackbird has to be bootstrapped by the ARM BMC - which is a nonfree ISA. Power consumption is another story as well. Raptor systems is definitely the only realistic competitor to x86_64, though, for desktop and server use-cases.
    - tpearson-raptor 7y ago
      Yep, definitely agreed. FWIW we're not happy with the ARM baseboard controller either and are making progress toward fixing that particular concern. All I'll say on that is that the POWER ISA opening had to happen before we could start work in earnest on getting rid of the ASpeed... ;)
zwegner 7y ago
> 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.

Sir_Cmpwn 7y ago

A race of one is easily won :)

tpearson-raptor 7y ago
Well, to be fair I was thinking of the SiFive RISC-V board as one of the competitors, since my understanding was they did finally open the rest of their firmware a while back. However, yes, by far most of the remaining owner controlled systems are even smaller -- some of the smaller (older) ARM Chromebooks (sans GPU, of course), the BeagleBone black, those kinds of systems.
- Sir_Cmpwn 7y ago
  Yeah, I also have a HiFive Unleashed which is totally open, but it doesn't really aim to compete with Raptor iiuc. Until recently it also won out on open ISA, too, and the Blackbird has to be bootstrapped by the ARM BMC - which is a nonfree ISA. Power consumption is another story as well. Raptor systems is definitely the only realistic competitor to x86_64, though, for desktop and server use-cases.
  - tpearson-raptor 7y ago
    Yep, definitely agreed. FWIW we're not happy with the ARM baseboard controller either and are making progress toward fixing that particular concern. All I'll say on that is that the POWER ISA opening had to happen before we could start work in earnest on getting rid of the ASpeed... ;)

zwegner 7y ago

> 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.