• Define how can a device be shared between multiple VMs.
• What state does a device needs to be in?

TODO: Did the ARM SPCI spec evolve on this?

ascull@ said:
The point has been raised that the current plan of giving devices stage-2 access to the whole VM address space may be unsuitable for reassignment.

Consider a VM which programs a device for an attack. The VM then gives that device to another VM allowing the device to gain access to all of its memory. The device is now in a position to read and modify memory, potentially take over the VM and then exfiltrate data. This highlights how we can't just think of devices as simply as we do memory and will need extra consideration with SPCI.

qwandor@ said:
Would resetting the device in some way whenever ownership is transferred solve this?

ascull@ said:
Resetting to a known safe state in the transfer would solve this but how it would be achieved is the difficulty. Drivers in the hypervisor increase surface, provides unnecessary privilege to the driver and makes the possibility of a single image across the ecosystem further away. Drivers in a VM would require special handling so they don't fall foul of problem we're trying to solve.

Some other options might be to include an acceptance stage in the transfer so the receiver can act on the device before giving the device access. I'm wondering whether this would fit in with the proposal for multi-way memory sharing but I haven't look at that too closely yet.

spmoreira@ said:
Stage 2 IOMMU mappings should be tied to a VM.

If VM A maps device X, it will have some IOMMU table B.

If A transfers X to VM P, then IOMMU table B must be disabled and a new
table Q must be setup tied to P (can be empty at first to mean access to
nothing). If A had setup a transaction to occur in while it reassigns X to
P, then the transaction would fail by the act of disabling B.

By convention, A should pause or flush X before passing it over to P, but
if it doesn't the IOMMU switch will stop it from being malicious by
accident or otherwise.

It should be an explicit action by P to enable the IOMMU on X, to reduce
race conditions between A -> disable B -> X mapped in P -> P.

...
I hadn't seen comment #1. If there is a wish to hand over a device from a VM to another, exclusively or shared, this could still happen but again, only the memory that needs to be accessed should be in IOMMU table.

• Shared as a loan = as per my comments in #5.
• Shared as with shared memory = same IOMMU table can be used, as long as only the memory that is needed is mapped.

As for the state the device should be in, it is my opinion that each VM should take care of that. Sender cleans up or receiver resets, I don't have a preference as long as the correct IOMMU tables are in place at the right time.

(Migrated from b/132396050.)