Hacker News

points by alanfranz 22 hours ago | 0 comments

I’m not sure I see a real threat here.

If you’re running an untrusted workload, you’re already running it.

Whether it can communicate with another untrusted workload, even though it should be separated, meh.

Unexpected? Probably. but I’m not sure it’s a security risk.

you might have an untrusted sandboxed workload that is not supposed to communicate externally handling secrets, and a different sandboxed workload able to communicate with the external world, not handling secrets.

[–] gregwebs 21 hours ago

The solution is to not have an untrusted workload handle secrets.

[–] usrusr 20 hours ago

One workload with observed radio discipline handling secrets, the other workload with a haystack of chatter that's not supposed to know about any of the secrets. When supply chain attack is in scope, trust only ever goes as far as misbehavior is observable. Cooperating workloads could be quite a powerful tool to make misbehavior less observable.

[–] mrguyorama 16 hours ago

"Extract secrets from someone else's running VM" is a well trodden cybersecurity path because AWS wants to be able to promise to you that running your very important workload in the same physical box as literal random script kiddies won't somehow screw you over.

[–] alanfranz 10 hours ago

I don’t see any indication that the untrusted workload could extract data from another _unwilling_ workload.

Side channels exist; but it doesn’t mean that all of them are a security risk.