Hacker News Reader

Comment by Tuna-Fish | Hacker News Reader

Yet less than 20% of the 80+ major vulnerabilities in confidential computing have been found by cloud companies, with the majority being found by universities and independent researchers.

It's not actually in their interest to look too closely. They know they are selling snake oil, and they do not care if it works. The only function of the technology, as far as they are concerned, is to be something they can market to customers who are scared at running on public cloud, and either they never intend to exploit it, in which case it doesn't matter if it doesn't work, or they do, in which case they don't want the vulnerabilities to be found and fixed. Either way, there is no upside to them for going spelunking.

View on HN

> It's not actually in their interest to look too closely. They know they are selling snake oil, and they do not care if it works.

I can tell you from direct experience on the inside at AWS that they care tremendously about virtualization security.

It's why they never let two tenants share a physical core simultaneously; they were prepared against side-channel attacks before Spectre and Meltdown were discovered.

It's why they never supported Intel SGX, preferring instead to sequester processors for confidential workloads (Nitro Enclaves), and why modern EC2 instances support memory encryption (Graviton + AMD SEV-SNP).

It's why, when you improperly remove a chassis from its cabinet, a mechanism destroys a key component containing the machine's attestation and encryption keys, rendering it useless.

It's why they delegated a large amount of security surface, including practically all I/O functions, to their off-CPU Nitro card.

They care tremendously about virtualization security, when the threat model is one of their tenants attacking another one of their tenants.

They care not one bit about virtualization security when the threat model is themselves attacking one of their tenants.

> They care not one bit about virtualization security when the threat model is themselves attacking one of their tenants.

This claim deserves substantiation. What evidence do you have of this?

Are you aware, for example, that their own personnel have no login capability to EC2 metal?

and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge because for example law enforcement agencies may demand that for one of there customers one day...

Fact is if you put it in the cloud you lost control. Data, services and integrity is gone. Uploading your stuff to Pirate Bay may actually be more secure because downloading it is maybe illegal :-)

> and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge

Such as what? Point to examples, please; don't just thread-crap hand-wavy statements like this.

Customers are free to--and are in fact encouraged to--use their own keys to encrypt their data both in transit and at rest.

> Fact is if you put it in the cloud you lost control. Data, services and integrity is gone.

The alternatives are arguably worse. You can't get anywhere near the durability of a cloud provider with any economically feasible alternative. Moreover, regardless of where you store data, law enforcement will be able to demand it be turned over with a valid warrant, and it's far easier for them to break down your door and collect it from your homelab servers (or just walk away with them under their arms) than to get into a Tier 1 cloud provider's data center and decrypt the encrypted data from it.

Is this a fair comparison? Why would we know about a cloud provider finding a vulnerability in their own product? Wouldn’t that be kept internal?

Vulnerabilities are typically fixed, and then reported.

Reported to whom? In this case, it's the cloud provider itself.

Reply on news.ycombinator.com