Hacker News

points by rcxdude 1 day ago | 0 comments

The microVMs probably don't have "two co-operating workloads are able to communicate" in their threat model. The main concern would be if a malicious payload was able to affect or extract data from any other VM.

[–] spockz 21 hours ago

I had to read this a few times. The difference is that with the OpenAI case there were two willing and determined parties, whereas the typical attack vector a microvm traditionally deals with is one malicious or compromised microVM trying extract data from another unwilling one.

[–] brookst 20 hours ago

Yes — and this isn’t really an attack. It’s an open signal channel between two microvm’s. If there was nobody intentionally listening in the other side you can shout into the ether as much as you want with no harm done.

The receiving side could be seen as a side channel attack, but not unique to LLMs.

[–] spockz 19 hours ago

I think it should classify as an escape or leak.

If one microVM can use the cpu in such a way that the registers can be used to communicate or exfiltrate/spy (the only difference being the directionality of the intent) by another microVM that is a leak on that microVM separation level.

[–] user43928 18 hours ago

Spy seems inappropriate if you can only read information stored in this side channel intentionally.

We'd first need to establish that this side channel leaks usable information during regular use.

[–] kenjackson 19 hours ago

This isn’t generally considered an attack, but I wonder if we will need to consider a new attack vector which is that AI agents may not be fully aligned and they may have incentive that is problematic and where working with other agents will maximize their chance of achieving the goal.

This is more associated with P(DOOM) scenarios, but I think we’re in a world where we have to take that seriously now.

[–] _blk 19 hours ago

Yup. clear the caches between switches and they'll start causing voltage spikes to communicate.