https://www.youtube.com/live/AcOPLWc-_UE?si=02njYCVqRZpj9SENIn the second video from
#EuroBSDCon, the presentation focused on Confidential Computing and bringing
#AMD #SEV (Secure Encrypted Virtualization) support to FreeBSD’s native hypervisor, `bhyve`. The talk broke down how hardware-enforced memory encryption isolates guest virtual machines from untrusted cloud providers and malicious host hypervisors.
The speaker walked through the zero-trust threat model, where an AES encryption engine built directly into the CPU's memory controller encrypts every byte of guest RAM on the fly.
By leveraging an isolated ARM-based co-processor the AMD Secure Processor encryption keys reside strictly within the hardware silicon throughout the VM's entire lifecycle. The host hypervisor acts as nothing more than an untrusted message router, meaning even a fully compromised host with root access sees only encrypted ciphertext when trying to dump guest memory.
To guarantee that the VM is running on genuine AMD hardware and untampered firmware, the implementation incorporates a robust remote attestation pipeline. Using the `sevctl` utility over a dedicated Unix domain socket exposed by `bhyve`, guest owners establish a secure Diffie-Hellman channel directly with the AMD Secure Processor.
They verify AMD's official certificate chain, validate a cryptographic measurement hash of the UEFI boot firmware (`OVMF`), and inject runtime secrets such as disk decryption keys—directly into encrypted guest RAM before the VM finishes booting.
A major technical highlight was overcoming multi-core (SMP) stability issues. In AMD SEV, a VM's encryption key is bound to a hardware Address Space Identifier (ASID). Standard hypervisors assign a fresh ASID when migrating a virtual CPU to a new physical core, which automatically clears out old Translation Lookaside Buffer (TLB) entries.
Because SEV keeps the exact same ASID across core hops, virtual CPUs were hitting stale memory mappings on old physical cores, causing frequent kernel crashes. The solution was implementing a targeted TLB flush for that specific ASID every time a virtual CPU migrates to a new core.
+++
