Hacker News new | ask | show | jobs
by pas 2166 days 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?

1 comments

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.

> You trust intel, and you trust their software and hardware does as advertised, but you don't need to trust the hosting company (Google).

I should note that this by itself is a fairly hilarious proposition.

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.