Expanding Google Cloud’s Confidential Computing Portfolio
cloud.google.com
cloud.google.com
Maybe I'm overly cynical, but I don't quite understand the target audience.
For basic security and isolation between tenants as well as intrusion prevention from third parties, I'd personally trust Google's SRE team more than any other cloud provider in the world. They seem to have a great historical record and if they had any slip ups there, their business would be impacted for years.
For access to state actors, I'd trust these machines not any bit more than conventional ones. If the key is held in memory, it's accessible. Even if it wasn't, the data would be captured at the storage layer boundary if it was of any interest.
* Planned obsolescence for most Google devices (Chromebooks, Android device, etc.) where security updates disappear after a few years. Contrast Linux, Windows, MacOS, etc.
* The number of Android devices silently running without security updates
* Google using basic security features as an upsell on GSuite. Pay us money, or your data will be compromised.
* Android app versus iPhone app security. Android apps scarf up all sorts of information about you, and you can't make it stop.
* Chrome versus Safari/Firefox privacy/security. Chrome makes tracking/ad/etc. blocking neigh impossible.
Good B2B companies take the attitude that if my business fails because of something they've done or could have prevented, they've failed. They're trusted partners. Azure and AWS operate somewhat this way. For GCE, I'm a statistic. If they do something which costs me $1,000,000 and saves them $1000, that's good business. That comes out of their consumer-as-a-product business lines, but it makes them nearly useless for B2B.
It's hitting their bottom line long-term; very little repeat business, and their reputation is in the gutter for B2B, but it's great for short-term metrics.
Google has only EOLd two Chromebooks ever, the Cr-48 that was supported from 2010-2015 and the Pixel, from 2013-2018. The current model is guaranteed to get updates through 2026. What's wrong with this?
And yes, it's Google's choice to kill these, not OEMs: Chromebooks are built according to certain platform specifications Google hands down, upon which they then support for a given amount of time. So claiming Google has only dropped updates for two Chromebooks ever, ignoring all of the third party manufactured ones, is dishonest.
Meanwhile, Windows, Linux, and macOS machines generally can run the latest version long past when the manufacturer supports it heavily. (Less true with Apple, but Apple's lifecycle is insanely long anyways.) You can actually take machines built to run Windows XP and install the latest release of Windows 10 on many of them. (It sometimes even runs decently too, if you use an SSD!)
Ironically, you can run the latest version of Chrome, via Windows 10, on PCs built for XP, but plenty of Chromebooks sold since then can't.
Additionally, Google has, like phones, positioned Chromebooks as disposable computing devices. $200-300 price point devices that you'll end up replacing in two or three years. Which is a massive e-waste problem, particularly given Google's push to get schools to force every student to buy/use them. For a supposedly green company, the entire Chromebook initiative should be seen as an embarrassing gap in good stewardship.
Note that this entire subthread is pretty off-topic to the original article though.
I did a 20% project on Chrome OS when I worked at Google. At the time, I happened to use a Wacom tablet as a mouse and Chrome OS as my primary OS, and so I backported all the upstream Wacom drivers to the various kernels used by the variety of Chrome OS devices. It was a ton of work, and I really only did it because I needed it myself and there was one really nice person on the bug tracker who supported the tablets at his school. But it doesn't scale -- this was the easiest and most trivial porting job imaginable, and it took me several hours each patch; not because applying the patch was hard, but because validating that it worked as expected took a long time. It was a 15 minute build per device, then I had to reflash, then I had to try all the Wacom devices I had laying around. Now imagine doing that with WiFi -- where your laptop has to work with hundreds of craptastic access points. It's a multi-week effort for every (device, patch) combination.
I don't work there anymore so I have no idea what the official policy is... but understand that it's, to some extent, the OEM's problem. They choose a WiFi chipset that breaks every kernel upgrade, and only they use it -- that's their validation to do. If they don't want to do it anymore they say "hey we saved three cents on the WiFi chipset, now throw away your laptop."
As to why this doesn't affect Windows... Microsoft has spent years building in compatibility for binary blob drivers. On my fresh install of Windows 10 I have drivers from 2008 that are running (for my USB webcam, sadly). The code hasn't changed, so they don't have to revalidate it. It just works, forever. But with Linux there is no such option; you have to make your code compile against the latest kernel, or your device stops working. Hardware vendors (and OEMs) are very lazy, and you can see that in action -- Android and Chrome OS devices stop getting updates because nobody will maintain the code. This, I suppose, is the cost of building atop a GPL-based operating system. Hardware is "design once and forget". Linux is "evolve and grow forever". The impedance mismatch between hardware vendors and software engineers leads to a bad user experience.
I am really curious about this claim, because I've installed Windows 10 on multiple Intel NUCs without any sort of issues. They've very well supported.
The only particular peeve I know of is that you can't install Windows Server 2016/2019 on an Intel NUC and use it's built-in Ethernet port, because Intel decided to disable allowing drivers for "consumer" Ethernet chips (like the one in most NUCs) to install on a server OS.
I'm sorry, but the problem here is Google. You're looking at this at a 10 foot engineer's view. I'm looking at this at a 10,000 foot view. Google has all the power in the world in this ecosystem. If it requires you to use one particular type of hardware... it can do that. If it requires you to open source all drivers... it can do that too. If it requires 20 years of support... that's within it's power.
And if it was a Linux problem, you couldn't get around it by installing Linux on some of the now-deprecated devices; I've seen people do that too. So Google doesn't just break the devices that are no longer supported. It's 100% planned.
The question then is, why bother with OEMs? But it's necessary to drive adoption: nobody wants to get fired over their choice of laptop vendor, and nobody ever got fired for picking Dell / HP / Samsung. But if you pick the weird upstart OS and anything goes wrong, you'll be blamed. So the OEMs exist to attach their credentials to the transaction -- "we'll be happy to sell you whatever laptops you want; you can have our Windows laptops for $2000 each or Chromebooks for $200 each". Now you at least have some excuse if things go bad -- "HP misled me! But we saved $1800 per student" or whatever.
When taking on a huge established incumbent, price and technical merits are not enough, and you can't go it alone. I don't think I'm looking at things from a "10 foot engineer's view" when I say that it will be very difficult to take on a company with 80% market share and 40 years of industry experience with your new Linux thingie. The OEMs are crucial there -- they have sales contacts, they have a brand that people trust, and people need to gradually warm up to the fact that there's a new OS in town that might save them some money. The cost there is that OEMs don't always do everything you want -- they have their own business to run and don't really need you to stay alive.
I think this argument held for the first year or two of Android, where they were a small player in the market.
...It simply doesn't hold today, where Google is a monopoly in mobile and one of the largest platforms in the education laptop space. OEMs live or die on Google working with them. Sales reps from major PC OEMs try to convince me to buy Chromebooks when I call them about Windows machines I need to buy.
There's no realistic claim today that Google doesn't have the clout or leverage to ensure their OS is supported properly. It's a choice.
https://eduproducts.withgoogle.com/products/category/chromeb...
Every Chromebook has a nicely listed expiration date. Past that date, security updates stop. At least in contrast to Android, they let you know.
I have old expired Chromebooks. They're insecure.
Most shops won't post the expiration date, and plenty of people buy Chromebooks with just a few months life left.
I own 3 chromebooks. The first one was purchased well over 5 years ago it still gets updates. My 2 kids have school chromebooks that they were issued when they started elementary school that they are expected to keep until they move on to middleschool. My son is going to middle school next year.
That is not the fault of Google but of SoC manufacturers (look inside leaked Mediatek kernel code / BSPs, the quality is horrenduous!), device manufacturers (for adding tons of bloatware that has to be certified for each Google/AOSP update) and carriers (for adding even MORE bloatware).
However, Google should finally add the requirement to fully open source everything needed to run stock Android (i.e. BSP, kernel and drivers) as criteria for Play Store certification.
Somehow, PCs get security updates.
That is why the situation is better there.
If Samsung decides not to play, Sony and Huawei will eat its market.
Huawei is not going to eat anyone's market so soon, not with Google having cut them off from Android.
https://arstechnica.com/gadgets/2019/11/google-outlines-plan...
Personal issues? I think you're projecting something.
I was responding to this comment: "I'd personally trust Google's SRE team more than any other cloud provider in the world. They seem to have a great historical record and if they had any slip ups there, their business would be impacted for years."
I'm not sure how commenting on Google's historical record is off-topic here, or what you mean by MY issues with the company.
I use many tools from Google. I avoid many other tools from Google. They're great at some things, and horrible at others. I don't think it's unfair to discuss those. Privacy and MY security aren't their forte. But most things I do aren't super-high security, so that's often okay.
> Maybe I'm overly cynical, but I don't quite understand the target audience.
No, that sounds about right.
Google Cloud's confidential computing is essentially a wrapper for AMD Secure Encrypted Virtualization (along with auditing tools), which is meant to be a physical protection measure. It can potentially protect against an attack like Rowhammer or Meltdown, but beyond that, Confidential Computing is primarily a protection mechanism if your threat model includes Google's own admins, which it might if you're in a heavily-regulated industry and have to tick a bunch of audit check boxes.
More critically, this can make cloud hosting an option for industries that previously rejected it due having to outsource system management to a third party. I don't know of any off-hand, but I have no doubt that they exist.
That being said, the allure of AMD SEV is that it provides encryption-in-use without worrying about performance, redesigning your applications, or overall having to think about it too much. If it's just a toggle you can flip and move on to other things, does it matter if the security benefit is only theoretical?
SEV can not protect against Rowhammer style issues because there is no cryptographic integrity protection on these implementations. That said, exploiting one or several bit flips in a cache line’s worth of encrypted memory is not trivial.
Of course we have to just take AMDs word for that. It would always be possible for AMD to push an update to the PSP that gives them access. I'm not saying that should be in the threat model of an ordinary person, but these machines are still backdoored by AMD.
Lets go through them.
> Of course we have to just take AMDs word for that.
I think this is obviously true. Nobody has ever done a public audit of AMDs 'secure instructions'.
> It would always be possible for AMD to push an update to the PSP that gives them access.
Assumptions here:
1. The PSP has access to the data protected by "secure instructions".
Given that the encryption is handled by the PSP, this is trivially true.
2. AMD can remotely push firmware updates to the PSP.
Assuming that the cloud services provider keeps the firmware up-to-date seems like a safe assumption to me. If they didn't, we would probably call their system insecure.
3. The PSP could be used to exfiltrate data.
Given that the PSP has full access to the machine, including the network system, this is also definitely true.
> I'm not saying that should be in the threat model of an ordinary person,
Simply stating that this paragraph should not be construed to imply that everybody msut leave AMD in masse introduces no new assumptions.
> but these machines are still backdoored by AMD.
This restates previous ideas, while making it sound more ominous. It also introduces no new assumptions.
Do you disagree with any of these assumptions? Or are you simply dismissing my comment by stating that there are "a lot" of assumptions despite the fact that all the assumptions are known to be true.
Federated distributed computing relates to what you're thinking of, but it is an extremely difficult topic, and veers into the realm of blockchains and things like that. There is also the whole area of Zero-Knowledge Proofs/Compute that deals with these matters: https://eprint.iacr.org/2013/229.pdf
If your threat model falls under the uber-paranoid category, you have to on-prem everything, preferrably inside your very own bunker. There is no getting around this afaik, and if there is there will probably be major tradeoffs (like the blockchain thingy) instead of a "drop-in" replacement for traditional compute.
https://www.microsoft.com/en-us/research/publication/shieldi...