[throwaway93382]

Is there anything else to these confidential machines other than feel-good, security theater or certification checkmarks?

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.

[theevilsharpie]

> Is there anything else to these confidential machines other than feel-good, security theater or certification checkmarks?

> 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?

[ENOTTY]

AMD was already free of meltdown style issues, with or without SEV. However AMD is susceptible to Spectre style issues.

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.

[nellydpa]

The keys used to encrypt the confidential VM memory is kept in the hw registers and not accessible and extractable by any sw, google or AMD. The keys are per a VM, ephemeral, so not stored anywhere. RE: storage level, you can encrypt your disk on the file system level if confidentiality of the data is important to you, dm-crypt with dm-verity are good choices. I agree with you that Google SREs are probably the best, no argument there.

[blendergeek]

> not accessible and extractable by any sw, google or AMD.

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.

[ikiris]

You're making a lot of assumptions here.

[blendergeek]

You say I am making "a lot of assumptions".

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.

[Donald]

I assume this is a pre-cursor for Google getting approved for classified cloud computing for government work, like Azure and AWS have.

[jeffbee]

I just think of it as cloud computing scheduled on AMD Zen2 CPUs with encrypted memory, nothing more or less than that. Maybe it is security theater but if it is, then encrypted memory is also.

[woofie11]

I wouldn't trust Google for security of MY data. I'd trust them for security of THEIR data. Examples:

* 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.

[jeffbee]

> Planned obsolescence for most Google devices (Chromebooks

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?

[ocdtrekkie]

The main issue is that it's a huge step backwards from PCs to treat laptops like phones that require model-specific updates. There are tons of Chromebook models that Google has abandoned, just not ones they themselves manufactured. The list is here: https://support.google.com/chrome/a/answer/6220366?hl=en

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.

[jrockway]

The underlying problem is Linux's driver model. To support new features, you have to support a new kernel. To support a new kernel, you have to port the device drivers to that kernel. Vendors don't like to maintain their code and changes in the kernel often break drivers, so vendors often just give up. That is basically the end of life for anyone that chooses hardware with bad drivers, which I guess some OEM Chromebook manufacturers did.

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.

[jeffbee]

I don't think the Windows model is all that great either. Windows 10 flat out refuses to install on an Intel NUC, which is about the most bog-standard "WinTel" machine you could imagine. Windows appears to work because vendors are motivated to integrate their drivers properly, and because running privileged driver installers from fly-by-night software vendors is socially acceptable in the Windows community.

[ocdtrekkie]

> Windows 10 flat out refuses to install on an Intel NUC

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.

[woofie11]

I guess I've never had that problem on my Linux desktop. I've had it for around a quarter-century now. There's a philosophical question whether it's the same desktop, since it has none of the original parts. I guess I've reinstalled the OS too, probably twice in the time.

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.

[jrockway]

Remember that Google has to convince OEMs to get behind their experimental free OS instead of Windows. They can't say "hey, you can have the OS for free, but now you need to keep specialty embedded engineers on staff until we say it's okay to stop maintaining drivers, which will be never" when Microsoft will probably happily negotiate down the cost of a Windows license to near $0 and pick up the driver maintenance as well.

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.

[UncleMeat]

People complain when google does what you are proposing too. Just look at how many people are aggravated about updating their apps to new android sdk versions, for example.

[ryukafalz]

This isn't a problem if you get your drivers upstreamed into mainline Linux, right? My understanding is the kernel community keeps in-tree drivers up to date as the kernel APIs change, and that's why I can install a modern version of Linux on just about any of the x86 machines I have lying around and expect (most of) the hardware to just work.

[woofie11]

Go to Google's store:

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.

[wmf]

I guess you're only counting Google-branded Chromebooks, because there are plenty of obsolete models listed. https://support.google.com/chrome/a/answer/6220366?hl=en

[mschuster91]

> The number of Android devices silently running without security updates

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.

[woofie11]

Google is the dominant force in this market. I'm sorry, but you can't pass the buck here.

Somehow, PCs get security updates.

[mschuster91]

Because PC manufacturers don't insist on modifying core Windows for their bloatware, and carriers don't insist on certification for each and every update.

That is why the situation is better there.

[woofie11]

If Google wanted, it could prohibit that practice. If you want Play Store, Youtube, Gmail, and all the other Googlies, you play by Google's rules. It ain't rocket science.

If Samsung decides not to play, Sony and Huawei will eat its market.

[mschuster91]

Sony is a fucking joke when it comes to software (no matter if cameras or phones). For what it's worth they're so small IDC doesn't even list them on the market share diagram: https://www.idc.com/promo/smartphone-market-share/vendor

Huawei is not going to eat anyone's market so soon, not with Google having cut them off from Android.

[anoncareer0212]

Well, Sony, at least. Finally a comeback from the Walkman!

[fomine3]

So Google tries to improve the situation.

https://arstechnica.com/gadgets/2019/11/google-outlines-plan...

[deelowe]

> Planned obsolescence for most Google devices

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.

[saagarjha]

Please don't use "Google" in the title as an opportunity to drag this thread into your personal issues with the company.

[woofie11]

?????

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.

[saagarjha]

You’re responding to a comment about Google Cloud with complaints about how Chrome OS devices don’t get updates as fast as you want them to. This is hardly on topic even if you stretch, and you shouldn’t because that drags the conversation into an unrelated place that is easier to respond to which is a perpetual danger on Hacker News.