Cool article! I'm working on a tangentially related issue requiring microVMs inside isolated infrastructure environments. Latency isn't really my main priority, but I am always tempted by any option to minimize attack surface. I wonder what it would take to replace the host block mount in this configuration with `vsock` for all communications between the host and guest microVM? Then you could avoid any files being mounted on the host at all while still enabling, e.g., one-way egress to a pre-signed S3 URL via a private VPC endpoint. Very cool article!
Amazon Nitro Enclave does pretty much this, the guest has one method of communication, via vsock, and it's up to you to build the pipes on either side.
It's a huge PITA in practice because whatever you want to run inside some enclave usually ends up being a 'normal program' that needs to talk TCP/IP over sockets... so your vsock I/O becomes a weird mix between a TUN proxy or a SOCKS5 local listener inside the VM that tunnels through vsock.
For example, I have the Windows NT 3.50 kernel compiling from scratch with virtio-net drivers, it's fairly straightforward for me to add a bus driver that runs over vsock inside Nitro Enclave that exposes itself (o,o) as a NIC then handle the tunneling logic in a usermode process in the host - but I don't uderstand the point of why you would do that when you already have sufficient attestation methods that don't require you to do vsock isolation.
Comments
Cool article! I'm working on a tangentially related issue requiring microVMs inside isolated infrastructure environments. Latency isn't really my main priority, but I am always tempted by any option to minimize attack surface. I wonder what it would take to replace the host block mount in this configuration with `vsock` for all communications between the host and guest microVM? Then you could avoid any files being mounted on the host at all while still enabling, e.g., one-way egress to a pre-signed S3 URL via a private VPC endpoint. Very cool article!
Amazon Nitro Enclave does pretty much this, the guest has one method of communication, via vsock, and it's up to you to build the pipes on either side.
It's a huge PITA in practice because whatever you want to run inside some enclave usually ends up being a 'normal program' that needs to talk TCP/IP over sockets... so your vsock I/O becomes a weird mix between a TUN proxy or a SOCKS5 local listener inside the VM that tunnels through vsock.
For example, I have the Windows NT 3.50 kernel compiling from scratch with virtio-net drivers, it's fairly straightforward for me to add a bus driver that runs over vsock inside Nitro Enclave that exposes itself (o,o) as a NIC then handle the tunneling logic in a usermode process in the host - but I don't uderstand the point of why you would do that when you already have sufficient attestation methods that don't require you to do vsock isolation.