4 ms·

Going to be worse than 30% slower by a lot.

BoorishBears 7y ago
What does this statement even mean? 30% slower for what? What workload? What environment? I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other! I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones” Do these vulnerabilities and the last live on the same hot paths? Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?
- redrabbyte 7y ago
  there are some (non-optimal) estimates in the paper, tl;dr it's not great ;) some more technical info here https://software.intel.com/security-software-guidance/insights/optimized-mitigation-approach-load-value-injection https://software.intel.com/security-software-guidance/insigh...
  - BoorishBears 7y ago
    Except how many lay people were running workloads where serializing SGX loads is back breaking? The tone of the original comment replied to definitely came from personal computing slant...
    - saagarjha 7y ago
      The problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.
    - redrabbyte 7y ago
      besides drm stuff like netflix (don't know if it's back breaking there), virtually none, of course unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm
- gameswithgo 7y ago
  the op seemed to be asking if we should remove speculative execution optimizations entirely to avoid these security problems. if we did that, the execution time, if averaged over all the workloads use, would be more than just 30% slower. the slowdown would be so large that i felt comfortable speaking in vague generalities, rather than providing specific benchmarks which pedants on the internet would also reply to in anger stating that it was not a real world workload or whatever. can’t win, so i don’t try.
  - BoorishBears 7y ago
    OP seemed to be doing no such thing. Period. If anything they’re asking the opposite! “Should we even be limiting the optimizations at all” They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all) Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.

What does this statement even mean? 30% slower for what? What workload? What environment? I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other! I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones” Do these vulnerabilities and the last live on the same hot paths? Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?

redrabbyte 7y ago
there are some (non-optimal) estimates in the paper, tl;dr it's not great ;) some more technical info here https://software.intel.com/security-software-guidance/insights/optimized-mitigation-approach-load-value-injection https://software.intel.com/security-software-guidance/insigh...
- BoorishBears 7y ago
  Except how many lay people were running workloads where serializing SGX loads is back breaking? The tone of the original comment replied to definitely came from personal computing slant...
  - saagarjha 7y ago
    The problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.
  - redrabbyte 7y ago
    besides drm stuff like netflix (don't know if it's back breaking there), virtually none, of course unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm
gameswithgo 7y ago
the op seemed to be asking if we should remove speculative execution optimizations entirely to avoid these security problems. if we did that, the execution time, if averaged over all the workloads use, would be more than just 30% slower. the slowdown would be so large that i felt comfortable speaking in vague generalities, rather than providing specific benchmarks which pedants on the internet would also reply to in anger stating that it was not a real world workload or whatever. can’t win, so i don’t try.
- BoorishBears 7y ago
  OP seemed to be doing no such thing. Period. If anything they’re asking the opposite! “Should we even be limiting the optimizations at all” They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all) Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.