71–80 of 119 posts
What secrets do typical VM hosts (like cloud service providers) have that must be protected from guests?
Private keys for HTTPS certificates. API keys or different credentials for other systems.
Earlier quoted context omitted.
Private keys for HTTPS certificates. API keys or different credentials for other systems.
Huh, interesting. VM _hosts_ serve HTTPS sites and hold API keys? Those aren't done by other servers?
Earlier quoted context omitted.
I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.
I upgraded from an i7-2600 to an 1800X over a year ago. Once the memory issues were solved (running at 3200 MHz vs ~2800 MHz), I've been happy with my purchase.
Earlier quoted context omitted.
Um, no. If I schedule a micro instance in a particular zone and nothing else, for the duration of my timeslice the VM will have to monopolize the core. Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT, which Google says it won’t do. Timeslicing doesn’t solve this problem. At least that’s my reading of what they said.
Re-read what I wrote above. It covered both simultaneous and sequential sharing. Here is the part you are concerned about: instances do not simultaneously share cores with other customer instances via SMT .
Earlier quoted context omitted.
Um, no. If I schedule a micro instance in a particular zone and nothing else, for the duration of my timeslice the VM will have to monopolize the core. Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT, which Google says it won’t do. Timeslicing doesn’t solve this problem. At least that’s my reading of what they said.
timeslicing works fine, you just have to flush the cache when switching
I'm tempted to just buy the cheapest 8th gen intel cpu and play with that to extract widevine keys from sgx
Earlier quoted context omitted.
There is a lot of legacy cruft in x86, but it's the devil we know. After decades of use, we are still discovering vulnerabilities, in a platform thought to be well-understood. The closest alternative would be ARM. In any case, it's a massive undertaking.
The closest alternative would be ARM On the contrary there's SPARC, MIPS, PA-RISC, POWER and a whole heap of others that perhaps were written off prematurely. Need to move quickly tho' while some vestiges of expertise still remain.
Getting the SGX attestation key would permanently break SGX-based blockchain (Hyperledger Sawtooth?) mining, if I understand correctly. It's amazing that (if this is correct) this vulnerability has permanently broken a large software project.
SGX Remote Attestation was built specifically to deal with events like this. Intel starts to reject attesting to vulnerable microcode revisions after some period following disclosure. In this case, they even postponed disclosure until patched microcode revisions were available and those revisions already required for successful attesation. If said SGX application wasn't built around this model then it's probably not…
-10%? -20%? -30%?
Have we gone back 3 CPU generations?