Could other major cloud providers boast this? It seems like Google's brand is benefiting tremendously from Project Zero in all of this. On the other hand, it feels nervous-makingly like a clear step towards running one's own mainstream hardware being too hard for the little guys.
Is that not how it's meant to work? They're paying to run a top notch security team which is actively discovering vulnerabilities and creating fixes for them. Should they not benefit from this?
One example of that might include patching your own hardware while waiting to offer the same capabilities to others.
My wife is an amazing and talented baker. But... any number of bakeries are better at rolling out a quality consistent product at scale.
Ditto with datacenters.
But if you are running your own hardware, you probably aren't sharing CPU time with strangers as GCP is.
The amount of platform complexity abstracted by the GCP services is staggering. This is the job of taking a (hopefully) understandable piece of computer code that represents some real-world logic and installing it into reality, in a sense. It's clear that it's a very messy world out there for a program.
Even if you aren't sharing with "strangers", applications may be vulnerable to these attacks. For example, the JavaScript attack clearly applies to people's individual computers. If you take untrusted code and execute it, you might be vulnerable to these intra-"instance" information leaks.
It all comes down to your threat model though. Some people are rightly worried about insider risk. If a malicious employee can go run a binary on your shared computing infrastructure to get root credentials out of a machine, that's actually a real problem. Then again, there are lots of ways for a rogue employee to do bad things, so this is "just" another one. But don't take this as "only applicable to shared cloud environments", because it's not.
The VM is not considered a security boundary any longer; tenancy controls are now in place, to prevent attacks similar to Meltdown and Spectre that are yet undiscovered.
Otherwise on a personal computer, if malware gets to execute in user mode, being able to access some machine private key is the least of our worries. The sensitive information is the documents stored on the machine, whether it is for them to be leaked or encrypted, if the code can access them in read/write, the party is already over.
Actually we have our Test Infrastructure seperated from the rest, so basically only this runs untrusted code.
To be like insurance companies, this is how their cloud business would have to work: you pay them $20,000 over ten years while receiving absolutely nothing tangible in return, until one day, ten years in, you need to utilize $25,000 in cloud services in a short burst. Then afterward, your bill goes up significantly, while as an industry they reduce what you get for that.
Beside that, there are exceptionally few things the little guy stands a chance at when competing head-on with a giant. The giant benefits from bargaining power at scale that is usually rather dramatic on most everything.
Eg Diapers.com was a well funded, well run ecommerce start-up. Amazon was going to destroy their business through scale leverage - applying plausibly anti-competitive below-cost tactics on core products like diapers - to put them under if they didn't agree to be acquired (Amazon had already begun applying that tactic in the lead-up to the acquisition, scaring the hell out of Diapers.com).
Not sure. AWS sent out alerts in early December than many instances needed a reboot, and would be force rebooted on 1/8 iirc. I'm guessing it was to handle patches that were put in place for these issues.
We were naturally first because we took action internally, but also because we didn't need to reboot guests to ship new kernels to hosts. We update kernels on our hosts frequently, and so nobody would have particularly noticed that their VMs underwent migrations (we do it all the time!).
I do not believe that HVM instances (which would be closer to your KVM infrastructure) needed to be rebooted.
Sometimes do not think they get the credit they deserve.
If it was a little guy who discovered it, then everyone except maybe a fraction of a percent of the world (or nobody if the discoverer runs no servers) gets the same late start.
Project Zero disclosed this to Intel, AMD and ARM on June 1 as stated in the blogpost [1]. I believe an independent researcher working somewhere else (or even at home) would have done the same, as indeed the parallel independent discoveries ultimately did.
[1] https://googleprojectzero.blogspot.com/2018/01/reading-privi...
I think it's also less statistically unlikely than you think. Thousands of security issues are discovered every year, it makes sense that some small number will be discovered in parallel. It looks like a big coincidence because you are focusing on the one parallel discovery, but if you consider it in the broad landscape of all discoveries then it's just statistically expected that there would be at least one parallel discovery.
No tinfoil hat: Because the series of research to date connected enough dots it crossed a threshold and lightbulbs went off all over.
Jann disclosed the issue to Intel in June. The subsequent activity around the KAISER patch was the reason we started investigating this issue.
Still, as they say in this article, without a tinfoil hat: "There’s no reason someone couldn’t have found this years ago instead of today."
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...
Funding and time/people for the kernel comes from the big players (IBM, Intel, et. al.) and distribution decisions have created a monoculture, making the big Linux distros feel like they're part of the corporate/national tech culture and less community centered.
DragonFly had a patch recently .. in master. OpenBSD just had a rant on their mailing list.
Somebody correct me if I'm wrong, but it looks like zero.
Its my understanding that Google disclosed this vulnerability to ARM, Intel, and AMD, and no one else, and left the hardware manufacturers the job of disclosing to the various software vendors. So, they gave 6 months to the people they disclosed the vulnerability to. Those people did or did not disclose it to others.
As you say, the vulnerability was disclosed to others on the 1st of June, which puts us at 6 months for the disclosure deadline. If 6 months in vendors aren't ready with patches I doubt those few days would have made a significant difference.