4 ms·

GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualizat

GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.

derefr 6y ago
> GCP does not have root access to the customers VMs I mean, they have physical access to the hypervisor host machines, where they could do anything they like to them, e.g. tap the JTAG pins of the CPU. Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.
- asah 6y ago
  This protects against remote rogue employees and intruders. As for physical attacks, Google is ultra paranoid about physical access to DCs, and I think we can quickly agree that rogue employees and outsiders would have little chance of successful attack given the outrageous (and secret) methods that Google employs. Remember, this is one of the most-attacked organizations in the world, they've had decades (plural) to enact defenses and test them, and a successful attack would cost them over $10 billion - there's a virtually unlimited budget for physical defense. Circa 2020, I'd put Google's physical intrusion defenses up against most military installations.
  - nitrogen 6y ago
    Is there something special that happens when a legit remote cloud user logs in that doesn't happen when a rogue remote Google admin logs in? Something that prevents a modified web client from stealing the creds during a user's web console session?
    - theevilsharpie 6y ago
      SEV protects against physical attacks. A rogue admin logging in through a management console would have to go through whatever controls and auditing the console's access control functionality provides.
    - deleted 6y ago
      [deleted]
  - frandroid 6y ago
    > decades (plural) Namely, two at most.
    - Kye 6y ago
      Is there a point of diminishing returns on experience for security? Two might be enough.
- remus 6y ago
  > Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much. For most people (and especially businesses) this is a totally unrealistic security aim. If what you're worried about is the government using it's legal ability to compel people and businesses to provide evidence then there's ~no product or service from that country that you could realistically use.
  - superkuh 6y ago
    Right. And now that this is a realistic and regular worry for normal businesses doing normal things the value proposition of the cloud is looking worse.
    - redblacktree 6y ago
      Are you suggesting that US companies should fear the US government may... steal their IP? I'm not being facetious, I just don't understand what the "realistic and regular worries" you cite are supposed to be.
  - derefr 6y ago
    I mean, yes, there's no service where the security/privacy is contractual, that is safe from the state overriding the contract. But the promise of things like homeomorphic encryption, is that you can do a computation on a truly untrusted substrate, i.e. you can trust computations performed by an untrusted adversary, and also know that they didn't learn anything about those computations. It's a technical solution to security/privacy, not a contractual one. The ideal that everyone's hoping for, is that there's a way to get that same kind of technical guarantee from cloud compute providers, without needing a layer of maths that makes Monte Carlo quantum simulation look fast.
    - Spooky23 6y ago
      All commercial activities are at the core protected by contractural protections and good faith. Cloud is not as different as you may think. Any other expectation of protection from the state are a limited based on probability, seriousness of the matter, and your potential culpability. Your employees, service providers and others can be required to provide information without informing you. In extreme cases, agents will pose as utility, security or building management.
- deleted 6y ago
  [deleted]
Dyaz17 6y ago
You can login to your instances from the admin console according to this : https://cloud.google.com/compute/docs/instances/connecting-to-instance https://cloud.google.com/compute/docs/instances/connecting-t... So Google has a way to login to your instances...
- pas 6y ago
  That's probably because there's an agent running on the default image. (Yes, duh, but if you disable that then they don't have "root".) Of course the question is basically moot, because unless they have some sort of third party append-only log of actions they perform on the hypervisors, how would anyone ever know? Yes, AMD this and Intel that, but since Google is building their own computers, and since it's close to impossible to verify that you are in fact running in the secure enclave ... then you should assume you aren't. Naturally, if you come up with a structure where you can incentivize Google to remain honest (eg. somehow make it evident to the world if they access or tamper with your stuff), then it becomes safe to delegate running VMs to them. Again, of course, the same problem comes up if you try to do it in-house. How do you verify the security staff at your data center is honest? CCTV? Who watches the watchers?
  - londons_explore 6y ago
    You could imagine a scheme in which the company running the data centers ran hypervisor software made by intel on chips made by intel. You trust intel, and you trust their software and hardware does as advertised, but you don't need to trust the hosting company (Google). The software would run your VM, and provide some kind of API which your VM could query to be sure it was running in a secure enclave, managed by Intel's signed software. The result of the API could be signed with Intel's key.
    - exikyut 6y ago
      That's pretty much the idea of SGX. But SGX has been broken multiple times, and because people love breaking SGX because it's such a "all the security eggs in one basket" design, it will virtually certainly be broken again in the future. Furthermore, SGX is reasonably disliked, inasmuch as people consider its equivalence to the security and boundary implications of the Management Engine.

derefr 6y ago

> GCP does not have root access to the customers VMs I mean, they have physical access to the hypervisor host machines, where they could do anything they like to them, e.g. tap the JTAG pins of the CPU. Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.

asah 6y ago
This protects against remote rogue employees and intruders. As for physical attacks, Google is ultra paranoid about physical access to DCs, and I think we can quickly agree that rogue employees and outsiders would have little chance of successful attack given the outrageous (and secret) methods that Google employs. Remember, this is one of the most-attacked organizations in the world, they've had decades (plural) to enact defenses and test them, and a successful attack would cost them over $10 billion - there's a virtually unlimited budget for physical defense. Circa 2020, I'd put Google's physical intrusion defenses up against most military installations.
- nitrogen 6y ago
  Is there something special that happens when a legit remote cloud user logs in that doesn't happen when a rogue remote Google admin logs in? Something that prevents a modified web client from stealing the creds during a user's web console session?
  - theevilsharpie 6y ago
    SEV protects against physical attacks. A rogue admin logging in through a management console would have to go through whatever controls and auditing the console's access control functionality provides.
  - deleted 6y ago
    [deleted]
- frandroid 6y ago
  > decades (plural) Namely, two at most.
  - Kye 6y ago
    Is there a point of diminishing returns on experience for security? Two might be enough.
remus 6y ago
> Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much. For most people (and especially businesses) this is a totally unrealistic security aim. If what you're worried about is the government using it's legal ability to compel people and businesses to provide evidence then there's ~no product or service from that country that you could realistically use.
- superkuh 6y ago
  Right. And now that this is a realistic and regular worry for normal businesses doing normal things the value proposition of the cloud is looking worse.
  - redblacktree 6y ago
    Are you suggesting that US companies should fear the US government may... steal their IP? I'm not being facetious, I just don't understand what the "realistic and regular worries" you cite are supposed to be.
- derefr 6y ago
  I mean, yes, there's no service where the security/privacy is contractual, that is safe from the state overriding the contract. But the promise of things like homeomorphic encryption, is that you can do a computation on a truly untrusted substrate, i.e. you can trust computations performed by an untrusted adversary, and also know that they didn't learn anything about those computations. It's a technical solution to security/privacy, not a contractual one. The ideal that everyone's hoping for, is that there's a way to get that same kind of technical guarantee from cloud compute providers, without needing a layer of maths that makes Monte Carlo quantum simulation look fast.
  - Spooky23 6y ago
    All commercial activities are at the core protected by contractural protections and good faith. Cloud is not as different as you may think. Any other expectation of protection from the state are a limited based on probability, seriousness of the matter, and your potential culpability. Your employees, service providers and others can be required to provide information without informing you. In extreme cases, agents will pose as utility, security or building management.
deleted 6y ago
[deleted]

Dyaz17 6y ago

You can login to your instances from the admin console according to this : https://cloud.google.com/compute/docs/instances/connecting-to-instance https://cloud.google.com/compute/docs/instances/connecting-t... So Google has a way to login to your instances...

pas 6y ago
That's probably because there's an agent running on the default image. (Yes, duh, but if you disable that then they don't have "root".) Of course the question is basically moot, because unless they have some sort of third party append-only log of actions they perform on the hypervisors, how would anyone ever know? Yes, AMD this and Intel that, but since Google is building their own computers, and since it's close to impossible to verify that you are in fact running in the secure enclave ... then you should assume you aren't. Naturally, if you come up with a structure where you can incentivize Google to remain honest (eg. somehow make it evident to the world if they access or tamper with your stuff), then it becomes safe to delegate running VMs to them. Again, of course, the same problem comes up if you try to do it in-house. How do you verify the security staff at your data center is honest? CCTV? Who watches the watchers?
- londons_explore 6y ago
  You could imagine a scheme in which the company running the data centers ran hypervisor software made by intel on chips made by intel. You trust intel, and you trust their software and hardware does as advertised, but you don't need to trust the hosting company (Google). The software would run your VM, and provide some kind of API which your VM could query to be sure it was running in a secure enclave, managed by Intel's signed software. The result of the API could be signed with Intel's key.
  - exikyut 6y ago
    That's pretty much the idea of SGX. But SGX has been broken multiple times, and because people love breaking SGX because it's such a "all the security eggs in one basket" design, it will virtually certainly be broken again in the future. Furthermore, SGX is reasonably disliked, inasmuch as people consider its equivalence to the security and boundary implications of the Management Engine.