Sandbox: fix RENAME_EXCHANGE alias bookkeeping on microVM virtio-fs shares #306

Follow-up from #296 / #302 (nanvix/openvmm#106). Related to #290.

Summary

The microVM virtio-fs server passes renameat2 flags through to the host, so RENAME_EXCHANGE works on Linux hosts. Its node bookkeeping, however, treats every rename as a one-way move:

• VirtioFs::rename calls remove_alias_prefix(new_path) and then rename_alias_prefix(old_path, new_path).
• After an exchange, the node that used to live at new_path loses its aliases. Its primary path stays at new_path, which now holds the other object. Both nodes therefore point at new_path.
• preflight_microvm_rename models the same one-way move when it checks the alias limits.

Impact

This cannot escape the export or bypass a denied path. Both names involved in an exchange must pass the denied-path check, and the confined host resolution added in nanvix/openvmm#106 never follows a symbolic link. It is a correctness problem: until the guest looks the name up again, operations on the swapped node can act on the other object. A snapshot taken in that window can also fail to save or restore. The guest normally revalidates the name first, because entries have zero cache lifetime, but a malicious or unusual client can hit the window.

Work

In OpenVMM (vm/devices/virtio/virtiofs), choose one of:

• Swap the alias prefixes and primary paths of both affected nodes for RENAME_EXCHANGE, and update preflight_microvm_rename to match.
• Reject RENAME_EXCHANGE (and RENAME_WHITEOUT) on microVM shares with EINVAL. Common build tools use plain rename, so this is likely safe.

Then add unit tests that exchange two files and two directories and check each node's path, aliases, and save/restore. Promote the OpenVMM pin in NVX.

Acceptance criteria

• After RENAME_EXCHANGE, each node either resolves to its own object at its new path, or the exchange is rejected without any host change.
• A snapshot taken right after an exchange saves and restores, or the exchange is rejected.