3 ms·

It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not.

archgoon 7y ago
> It's secure or its not. Then there is no concept of "improves" security. Either it is now secure or it is not. Do they have proof that there are now no side channel attacks that can be made on their software? EDIT: sigh This comment is not arguing that they need a proof for their change. It is arguing that you can improve security without making something completely secure, which undermines the idea that code is 'either secure or it is not'.
simias 7y ago
There are a lot of knee-jerking in this thread. I don't think anybody is arguing that this is a bad patch, but if it does have a notable performance impact (which it probably does not) it's still worth knowing. If only to be able to answer questions like "why do our backups suddenly take 10% more time to complete? Do we have a problem with our network infrastructure?" It's not about tradeoffs, it's about understanding what's going on and anticipating potential problems. By your logic we shouldn't have to discuss the performance regressions on CPUs who implement spectre/meltdown mitigations because "it's irrelevant". Obviously these patches are necessary but the performance impact is very relevant for many users.
- archgoon 7y ago
  By the parent's logic, there's no concept of improving security, because if there remains attacks, then it is still not secure. You can't take a position of "it's either secure or it isn't."
yjftsjthsd-h 7y ago
I don't think that makes sense. For starters, threat model is everything. To grab an obvious example here, speculative execution attacks are only a concern if an attacker can cause execution of code on your physical host. A secure program facing the network will be secure even if it fails to defend against CPU side channels. Further, reducing to a binary de facto means that literally everything is "insecure", the end. (I defy you to show me a piece of software that never has had any vulnerabilities and never will, since of course undiscovered bugs still make the system insecure)
mehrdadn 7y ago
> It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not. Everything in the world is about trade-offs. Security is no exception. Humans figured this out a long time ago with physical security. Somehow it hasn't sunk in for cybersecurity. I would recommend mentioning this to a well-known security expert if you ever come across one and seeing their reaction.
ncmncm 7y ago
Degree of security is routinely measured by expense to overcome it.
firethief 7y ago
> It's secure or its not. Well, it's not. Now that we've debunked performance and security, I guess we can just write everything in PHP.
carapace 7y ago
I think folks are missing your point, which (I think) is something like: I don't care if that car is faster if it is already on fire.

archgoon 7y ago

> It's secure or its not. Then there is no concept of "improves" security. Either it is now secure or it is not. Do they have proof that there are now no side channel attacks that can be made on their software? EDIT: sigh This comment is not arguing that they need a proof for their change. It is arguing that you can improve security without making something completely secure, which undermines the idea that code is 'either secure or it is not'.

simias 7y ago

There are a lot of knee-jerking in this thread. I don't think anybody is arguing that this is a bad patch, but if it does have a notable performance impact (which it probably does not) it's still worth knowing. If only to be able to answer questions like "why do our backups suddenly take 10% more time to complete? Do we have a problem with our network infrastructure?" It's not about tradeoffs, it's about understanding what's going on and anticipating potential problems. By your logic we shouldn't have to discuss the performance regressions on CPUs who implement spectre/meltdown mitigations because "it's irrelevant". Obviously these patches are necessary but the performance impact is very relevant for many users.

archgoon 7y ago
By the parent's logic, there's no concept of improving security, because if there remains attacks, then it is still not secure. You can't take a position of "it's either secure or it isn't."

yjftsjthsd-h 7y ago

I don't think that makes sense. For starters, threat model is everything. To grab an obvious example here, speculative execution attacks are only a concern if an attacker can cause execution of code on your physical host. A secure program facing the network will be secure even if it fails to defend against CPU side channels. Further, reducing to a binary de facto means that literally everything is "insecure", the end. (I defy you to show me a piece of software that never has had any vulnerabilities and never will, since of course undiscovered bugs still make the system insecure)

mehrdadn 7y ago

> It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not. Everything in the world is about trade-offs. Security is no exception. Humans figured this out a long time ago with physical security. Somehow it hasn't sunk in for cybersecurity. I would recommend mentioning this to a well-known security expert if you ever come across one and seeing their reaction.

ncmncm 7y ago

Degree of security is routinely measured by expense to overcome it.

firethief 7y ago

> It's secure or its not. Well, it's not. Now that we've debunked performance and security, I guess we can just write everything in PHP.

carapace 7y ago

I think folks are missing your point, which (I think) is something like: I don't care if that car is faster if it is already on fire.