31–40 of 406 posts
Pick at most 2: Sharing of computing resources Performance Security
Other people in this thread: Just disable turbo boost!
cloud providers: quivering over the cost implications of either.
Earlier quoted context omitted.
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…
> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
"The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.
Pick at most 2: Sharing of computing resources Performance Security
Does this mean that an evil process may gain information about a foreign process by measuring its own execution speed variations?
That is my reading of the text on the linked page. >We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.
If you created an algorithm that evaluated all possible 32 bit inputs in parallel and then picked the correct value at the end based on the input, you'd still have some funky corner case where the branch predictor in your x64 processor spilled the beans. Are we going to have to design our crypto algorithms entirely on SIMD instructions to combat this sort of thing?
I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.
What’s constant time? Crypto libraries need to do operations to encrypt and decrypt your data. The simple, naive implementation of these operations will work - giving correct input and output. However, a person can time the operation being performed and learn about the key being used. If you’ve deployed on a server and the other person can submit any text they want, whenever they want, they would be able to extract the key from your naive implementation. That’s bad, the worst outcome possible.
That’s why good libraries will make sure that these operations take the same amount of time, regardless of input. So we thought we were safe.
And now these authors tell us, no. That’s not the case. The guidelines used by crypto library developers don’t protect against the attack being described here.
Does this mean platforms such as JavaScript in the browser are unable to exploit this?
Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected?
Is the longer term fix then to make reading of any compute metrics a privileged operation?
Earlier quoted context omitted.
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…
> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
Earlier quoted context omitted.
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…
> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
The only reason why resources might be left unused are usage spikes that all customers share.
Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…
Considering how easy it is to turn on/off (on macOS at least I used Turbo Boost Switcher which added a button in the menu bar to toggle it) I don't think you would have a noticeable performance hit by keeping it off except when you need it.
Earlier quoted context omitted.
> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
I think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server? "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.