4 ms·

Reading this got me wondering about the bigger picture trade-off between security and performance. Is there a reasonable way to estimate how much performance c

Reading this got me wondering about the bigger picture trade-off between security and performance. Is there a reasonable way to estimate how much performance could be gained if we operated in a hypothetical universe where we never ever had to worry about security?

ashvardanian 3y ago
It depends on the solution. The paper referenced in the article suggests "≈ 0%-1.94% in SPEC CPU2017 and ≈0%-1.92% in real-world applications"..., which is extremely impressive. In my practice, the costs are generally much higher. paper: https://arxiv.org/abs/2303.16353 https://arxiv.org/abs/2303.16353
MailNerd 3y ago
Most of these techniques are engineered to not cause much of a performance degradation. Otherwise there would not be much uptake. Also they are often implemented in compilers which produce native binaries so the impact is low. The mitigations for the various hardware sidechannel attacks discovered in the past year have a bit larger impact. But you don't need these at all on your local computer, only in shared environments. As a rule of thumb each mitigation usually costs a single digit percentage, seldom double digit. Of course in a system multiple mitigations will be at play but the impact should be far below 100%. The performance impact of scripting languages, interoperable web standards and bad implementations are far worse :)
a1369209993 3y ago
> Is there a reasonable way to estimate how much performance could be gained if we operated in a hypothetical universe where we never ever had to worry about security? Not really, no. In the limit of a theoretically perfect implementation, the performance overhead of security is zero (except to the extent that you count cryptography, but that's distinct from CFI/RCE/memory-corruption/etc-style security). The practical overhead basically comes from defence-in-depth to insure that imperfect implementation don't break security, and there's not in general any fundamental reason why imperfection A is common problem that needs to be mitigated, but imperfection B is a stupid corner case deserving of "well, don't do that then". Also we essensially -by-definition don't have a theoretically perfect implementation to compare against, so we can't even estimate the zero-overhead point with any confidence.
paulddraper 3y ago
> how much performance could be gained One place to look at would be TLS perf. Network latency, encryption compute.

ashvardanian 3y ago

It depends on the solution. The paper referenced in the article suggests "≈ 0%-1.94% in SPEC CPU2017 and ≈0%-1.92% in real-world applications"..., which is extremely impressive. In my practice, the costs are generally much higher. paper: https://arxiv.org/abs/2303.16353 https://arxiv.org/abs/2303.16353

MailNerd 3y ago

Most of these techniques are engineered to not cause much of a performance degradation. Otherwise there would not be much uptake. Also they are often implemented in compilers which produce native binaries so the impact is low. The mitigations for the various hardware sidechannel attacks discovered in the past year have a bit larger impact. But you don't need these at all on your local computer, only in shared environments. As a rule of thumb each mitigation usually costs a single digit percentage, seldom double digit. Of course in a system multiple mitigations will be at play but the impact should be far below 100%. The performance impact of scripting languages, interoperable web standards and bad implementations are far worse :)

a1369209993 3y ago

> Is there a reasonable way to estimate how much performance could be gained if we operated in a hypothetical universe where we never ever had to worry about security? Not really, no. In the limit of a theoretically perfect implementation, the performance overhead of security is zero (except to the extent that you count cryptography, but that's distinct from CFI/RCE/memory-corruption/etc-style security). The practical overhead basically comes from defence-in-depth to insure that imperfect implementation don't break security, and there's not in general any fundamental reason why imperfection A is common problem that needs to be mitigated, but imperfection B is a stupid corner case deserving of "well, don't do that then". Also we essensially -by-definition don't have a theoretically perfect implementation to compare against, so we can't even estimate the zero-overhead point with any confidence.

paulddraper 3y ago

> how much performance could be gained One place to look at would be TLS perf. Network latency, encryption compute.