5 ms·

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

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.

Donald 6y ago
I assume this is a pre-cursor for Google getting approved for classified cloud computing for government work, like Azure and AWS have.
woofie11 6y ago
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 6y ago
  > 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?
  - wmf 6y ago
    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 https://support.google.com/chrome/a/answer/6220366?hl=en
  - ocdtrekkie 6y ago
    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 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.
jeffbee 6y ago
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.
theevilsharpie 6y ago
> 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 6y ago
  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 6y ago
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 6y ago
  > 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 6y ago
    You're making a lot of assumptions here.
    - blendergeek 6y ago
      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 6y ago

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

woofie11 6y ago

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 6y ago
> 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?
- wmf 6y ago
  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 https://support.google.com/chrome/a/answer/6220366?hl=en
- ocdtrekkie 6y ago
  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 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.

jeffbee 6y ago

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.

theevilsharpie 6y ago

> 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 6y ago
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 6y ago

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 6y ago
> 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 6y ago
  You're making a lot of assumptions here.
  - blendergeek 6y ago
    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.