LY Corporation's implementation of Confidential VM ensuring privacy for AI features

This session introduces our work on "Confidential VM," a new feature provided by Flava, LY Corporation's internal cloud platform, that enables data owners to request data processing more securely.
LY Corporation provides services that use AI, and some of these services handle private user information. For this reason, processing such data on a cloud platform requires a high level of security.
Flava provides "Confidential VM," a feature that uses AMD CPU SEV-SNP technology to allow clients to verify the security of data processing.
This makes it possible to ensure that input data for AI cannot be accessed not only by infrastructure administrators, but also by service administrators. This feature is expected to meet a broad range of requirements for applying higher security standards to data processing, extending beyond AI workloads.
This session helps those who are unfamiliar with Confidential VM understand its value and how it can be used.

Transcript

1. 2026.06.29 LY Corporation Hiroki Narukawa Akihiro Misawa Masataka Minoji LY Corporation's implementation of Confidential VM ensuring privacy for AI features
2. Hiroki Narukawa / 成川 弘樹 Cloud Infrastructure Unit Mainly working on software running inside hypervisors including low-layer. Masataka Minoji / 美濃地 正貴 Cloud Infrastructure Unit Interested in virtualization of dedicated uses like accelerators. Akihiro Misawa / 三澤 明寛 Server & OS Division Infrastructure engineer focused on server OS operations and automation tool development. Speakers
3. Our goal: ensuring better privacy in LINE AI What is Confidential VM? How we realize: implementation in OpenStack within Flava, our private cloud Application deployment: how we keep service application trusted 1 3 2 4 Agenda
4. Our goal: ensuring better privacy in LINE AI What is Confidential VM? How we realize: implementation in OpenStack within Flava, our private cloud Application deployment: how we keep service application trusted 1 3 2 4 Agenda
5. - We provides AI services handling private user information. - To ensure even higher level of security, security model which does not trust hypervisors is better. Our goal: Privacy in AI features Hypervisors (HVs; Physical machines hosting VMs) VMs Applications Hypervisors (HVs; Physical machines hosting VMs) Confidential VMs Applications Boundary AS IS TO BE Narrower trusted area
6. “Flava” is our private cloud. - Designed to provide a unified, scalable, and reliable infrastructure for all our services. - Providing a wide range of services from IaaS to PaaS for our developers. - Flava IaaS is based on OpenStack. Flava started providing “Confidential VM” (CVM), which improves security of AI features. LY Corporationʼs private cloud “Flava”
7. - For Confidential VM, there are actual use cases as service - Implementation to achieve the goal was not enough in OpenStack (OSS used in our private cloud) - There was no common reference about how to attest application Gap between our goal and start point
8. Our goal: ensuring better privacy in LINE AI What is Confidential VM? How we realize: implementation in OpenStack within Flava, our private cloud Application deployment: how we keep service application trusted 1 3 2 4 Agenda
9. Confidential VM: Isolated VM within special area of CPU - AMD SEV-SNP: provides Confidential VM in AMD CPU - Intel TDX: provides Confidential VM in Intel CPU Our Confidential VM (CVM) is based on AMD SEV-SNP VM. What is Confidential VM?
10. System configuration Scheduler HV 2 for Confidential VM Other HV Mobile Phone App HV 1 for Confidential VM Confidential VM BIOS+Linux opt: app=abc Secure Channel
11. System configuration Scheduler HV 2 for Confidential VM Other HV Mobile Phone App HV 1 for Confidential VM Confidential VM BIOS+Linux opt: app=abc Secure Channel
12. Security model which does not “trust” HVs Mobile Phone App Hypervisor Confidential VM BIOS+Linux opt: app=abc Secure Channel Trusted Untrusted Goal: Mobile phone app can send private messages to Confidential VM via secure channel. The security model does not “trust” hypervisors; mobile phone app should keep safety by itself
13. What does Attestation Report show? Attestation Report includes: - Measurement: SHA384 hash value of memory loaded when VM is booted Mobile Phone App Hypervisor Secure Channel Confidential VM BIOS+Linux opt: app=abc Attestation Report Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234
14. What does Attestation Report show? Mobile Phone App Hypervisor Secure Channel Confidential VM BIOS+Linux opt: app=abc Attestation Report Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Direct Kernel Boot: VM booting method which loads kernel into memory at first The following are folded into Measurement SHA384: - BIOS of VM - In direct kernel boot, - Kernel & initrd - Kernel options
15. Why can client trust Attestation Report? Mobile Phone App Hypervisor Confidential VM BIOS+Linux opt: app=abc Attestation Report Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Attestation Report is signed by genuine AMD Secure Processor. Attestation Report can be verified using AMD certificate chain. Secure Channel
16. Why can client trust Attestation Report? Mobile Phone App Hypervisor Confidential VM BIOS+Linux opt: app=abc Attestation Report Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Here, the mobile phone app could believe Attestation Report. Therefore, the app can also trust Confidential VM Secure Channel
17. Why can mobile app trust the server? Mobile Phone App Hypervisor Key hash 0x5678 Confidential VM BIOS+Linux opt: app=abc Attestation Report Public key hash: 0x5678 Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Attestation Report includes: - Hash of public key for VM application Secure Channel
18. If the software is modified? Mobile Phone App Hypervisor Key hash 0x5678 Confidential VM BIOS+Linux opt: app=def Attestation Report Public key hash: 0x5678 Measurement: 0x12ab ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Changed Mismatc h If the software running inside the VM is modified? - Measurement changes. In this case, mobile client can detect contamination and stop sending sensitive information. Modified Secure Channel
19. If Attestation Report is not genuine? Mobile Phone App Hypervisor Confidential VM BIOS+Linux opt: app=def Key hash 0x5678 Attestation Report Public key hash: 0x5678 Measurement: 0x1234 × Not signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Failure Lie Modified - If someone tried to generate Attestation Report with false value? - If the CPU is not genuine AMD processor? Mobile app detects that the signature of the Attestation Report does not pass the verification. Secure Channel
20. If an attack reuses Attestation Report? Mobile Phone App Hypervisor Key hash 0x56cd Confidential VM BIOS+Linux opt: app=abc Attestation Report Public key hash: 0x5678 Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Reused Mismatch - Mobile app tries to verify the channel with the public key provided in Attestation Report (0x5678) - Attacker does not have the corresponding private key. (uses 0x56cd) This time, the connection fails. Secure Channel
21. By this configuration, client can establish secure channel to Confidential VM with: - Genuine AMD CPU - Known BIOS - Known kernel - Known kernel options Client can establish secure channel with trust Mobile Phone App Hypervisor Confidential VM BIOS+Linux opt: app=abc Secure Channel Key hash 0x5678 Attestation Report Public key hash: 0x5678 Measurement: 0x1234 ✓ Signed by genuine AMD Processor Known Trusted VM hashes hash: 0x1234 BIOS+Linux opt: app=abc Trusted Untrusted
22. Our goal: ensuring better privacy in LINE AI What is Confidential VM? How we realize: implementation in OpenStack within Flava, our private cloud Application deployment: how we keep service application trusted 1 3 2 4 Agenda
23. To realize security model with untrusted hypervisor: To implement our Confidential VM support on our private cloud: 1. Enable to boot Confidential VM - Implement SEV-SNP 2. Enable to verify Attestation Report - Guarantee BIOS, kernel and kernel option - adapted boot method “Direct kernel boot” - Provide certificate to VMs to verify Attestation Report Implementation of our Confidential VM
24. System configuration Mobile Phone App HV for CVM Confidential VM BIOS+Linux opt: app=abc Secure Channel
25. We support to boot Confidential VM, by implementing SEV-SNP Support on OpenStack. To specify parameters on virtualization middleware (libvirt) We provide unified interface to users, similar to non-Confidential VMs: 1. Enable to boot Confidential VM $ openstack server create --image "Rocky Linux:CVM" --flavor 8vCPU_16GiB_10GiB.CVM_AMD_26_2_1 --property cmdline=” container=example.com/my/container image_sha256=abcdef"
26. Confidential VM needs long kernel parameters like image hashes. →We have extended kernel command line over 255 characters. Upstreaming SEV-SNP support to OpenStack community. →Published OpenStack development documentation and source code. Ref: https://review.opendev.org/c/openstack/nova-specs/+/983376 Upstreaming SEV-SNP Support
27. Confidential VM To guarantee attestation report, “OS Image” for Confidential VMs must have following items (direct kernel boot) Moreover, users application is executed as application container. This is because: - Separate OS image and application images - Guarantee that both OS Image and Application Images are not changed 2. Enable to verify Attestation Report Application Container OS Image OS snapshot VM BIOS Kernel Options Kernel & initrd
28. SEV-SNP VM must provide “VCEK certificate” (Versioned Chip Endorsement Key). - VCEK certificate is needed to attest that the Attestation Report is genuine and verifiable. - VCEK certificate is corresponding to each physical CPU. - VCEK certificate is available at AMD server. → We saved the certificate on each hypervisors in advance. - VM are in air-gapped environment - cannot access AMD server from VM - To avoid to rely on connectivity to AMD server every time VM boots Provide VCEK to verify Attestation Report
29. Our goal: ensuring better privacy in LINE AI What is Confidential VM? How we realize: implementation in OpenStack within Flava, our private cloud Application deployment: how we keep service application trusted 1 3 2 4 Agenda
30. System configuration Hypervisor 1 for CVM CPU: 26.2.1 Confidential VM BIOS+Linux Application Container kernel params: app=abc launch OS
31. What is trusted service state? Hypervisor 1 for CVM Confidential VM BIOS+Linux service Application Container OS launch developer etc. Specified service is launched without modification Running service remains unmodified after launch
32. How can we trust a service running in a CVM? Hypervisor 1 for CVM Confidential VM BIOS+Linux service Application Container OS developer etc. kernel params: os_root_hash container_hash specify service identity is bound to attestation via kernel parameters OS configuration to block external modification
33. Kernel parameters contain hashes identifying the OS and service application - OS state hash: dm-verity - Service app container image hash: in-house container launcher Specifying and launching the OS and service app service Application Container OS Hypervisor 1 for CVM Confidential VM BIOS+Linux dm-verity in-house container launcher verify hash and launch OS and application container kernel params: os_root_hash container_hash
34. Verifying OS integrity with dm-verity kernel param attestation report OS (root filesystem) OS (root filesystem) dm-verity os_root_hash=0x12ab os_root_hash=0xcd34 measurement=0x567e measurement=0x891f Mismatch Mismatch 👿 Trusted Untrusted Any modification to the root filesystem results in a different root hash.
35. The root filesystem remains read-only and verifiable through dm-verity. Service provisioning changes are stored in a RAM-backed overlay filesystem Immutable root filesystem, writable runtime state dm-verity protected root filesystem (Read-Only) RAM OverlayFS (Writable) Application No changes Changes stored in OverlayFS
36. Verifying service app integrity with container image hash kernel param attestation report container image A container image B container_image_hash=0x3333 container_image_hash=0x5555 measurement=0x15ae measurement=0x26bf Trusted Untrusted Mismatch Mismatch 👿 A different container image results in a different image hash.
37. The in-house launcher retrieves and launches the container specified in kernel parameters. In-house container launcher container image registry Confidential VM service app launcher 2. pull image 0x3333 1. parse OS (root filesystem) kernel param container image A container_image_hash=0x3333 3. launch
38. Prevent changes to the OS configuration and service app. Users can launch own application container via kernel parameters. Confidential VM Preserving OS and service app integrity service Application Container OS developer etc. No access via SSH, console login
39. - Sensitive AI workloads benefit from a security model that does not trust privileged infrastructure - SEV-SNP Attestation Reports enable secure communication with Confidential VMs - Implemented SEV-SNP Confidential VM support for OpenStack and contributed it upstream - Extend trust from the Confidential VM to the application container Summary