요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
Confidential Computing VMs
==========================
Hyper-V can create and run Linux guests that are Confidential Computing
(CoCo) VMs. Such VMs cooperate with the physical processor to better protect
the confidentiality and integrity of data in the VM's memory, even in the
face of a hypervisor/VMM that has been compromised and may behave maliciously.
CoCo VMs on Hyper-V share the generic CoCo VM threat model and security
objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
"isolation VMs".
A Linux CoCo VM on Hyper-V requires the cooperation and interaction of the
following:
* Physical hardware with a processor that supports CoCo VMs
* The hardware runs a version of Windows/Hyper-V with support for CoCo VMs
* The VM runs a version of Linux that supports being a CoCo VM
The physical hardware requirements are as follows:
* AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
SEV, or SEV-ES encryption, and such encryption is not sufficient for a CoCo
VM on Hyper-V.
* Intel processor with TDX
To create a CoCo VM, the "Isolated VM" attribute must be specified to Hyper-V
when the VM is created. A VM cannot be changed from a CoCo VM to a normal VM,
or vice versa, after it is created.
Operational Modes
-----------------
Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
created and cannot be changed during the life of the VM.
* Fully-enlightened mode. In this mode, the guest operating system is
enlightened to understand and manage all aspects of running as a CoCo VM.
* Paravisor mode. In this mode, a paravisor layer between the guest and the
host provides some operations needed to run as a CoCo VM. The guest operating
system can have fewer CoCo enlightenments than is required in the
fully-enlightened case.
Conceptually, fully-enlightened mode and paravisor mode may be treated as
points on a spectrum spanning the degree of guest enlightenment needed to run
as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A full
implementation of paravisor mode is the other end of the spectrum, where all
aspects of running as a CoCo VM are handled by the paravisor, and a normal
guest OS with no knowledge of memory encryption or other aspects of CoCo VMs
can run successfully. However, the Hyper-V implementation of paravisor mode
does not go this far, and is somewhere in the middle of the spectrum. Some
aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
must be enlightened for other aspects. Unfortunately, there is no
standardized enumeration of feature/functions that might be provided in the
paravisor, and there is no standardized mechanism for a guest OS to query the
paravisor for the feature/functions it provides. The understanding of what
the paravisor provides is hard-coded in the guest OS.
Paravisor mode has similarities to the `Coconut project`_, which aims to provide
a limited paravisor to provide services to the guest such as a virtual TPM.
However, the Hyper-V paravisor generally handles more aspects of CoCo VMs
than is currently envisioned for Coconut, and so is further toward the "no
guest enlightenments required" end of the spectrum.
.. _Coconut project: https://github.com/coconut-svsm/svsm
In the CoCo VM threat model, the paravisor is in the guest security domain
and must be trusted by the guest OS. By implication, the hypervisor/VMM must
protect itself against a potentially malicious paravisor just like it
protects against a potentially malicious guest.
The hardware architectural approach to fully-enlightened vs. paravisor mode
varies depending on the underlying processor.
* With AMD SEV-SNP processors, in fully-enlightened mode the guest OS runs in
VMPL 0 and has full control of the guest context. In paravisor mode, the
guest OS runs in VMPL 2 and the paravisor runs in VMPL 0. The paravisor
running in VMPL 0 has privileges that the guest OS in VMPL 2 does not have.
Certain operations require the guest to invoke the paravisor. Furthermore, in
paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
as defined by the SEV-SNP architecture. This mode simplifies guest management
of memory encryption when a paravisor is used.
* With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
L1 VM. In paravisor mode, TD partitioning is used. The paravisor runs in the
L1 VM, and the guest OS runs in a nested L2 VM.
Hyper-V exposes a synthetic MSR to guests that describes the CoCo mode. This
MSR indicates if the underlying processor uses AMD SEV-SNP or Intel TDX, and
whether a paravisor is being used. It is straightforward to build a single
kernel image that can boot and run properly on either architecture, and in
either mode.
Paravisor Effects
-----------------
Running in paravisor mode affects the following areas of generic Linux kernel
CoCo VM functionality:
* Initial guest memory setup. When a new VM is created in paravisor mode, the
paravisor runs first and sets up the guest physical memory as encrypted. The
guest Linux does normal memory initialization, except for explicitly marking
appropriate ranges as decrypted (shared). In paravisor mode, Linux does not
perform the early boot memory setup steps that are particularly tricky with
AMD SEV-SNP in fully-enlightened mode.
* #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
CoCo VM to route #VC and #VE exceptions to VMPL 0 and the L1 VM,
respectively, and not the guest Linux. Consequently, these exception handlers
do not run in the guest Linux and are not a required enlightenment for a
Linux guest in paravisor mode.
* CPUID flags. Both AMD SEV-SNP and Intel TDX provide a CPUID flag in the
guest indicating that the VM is operating with the respective hardware
support. While these CPUID flags are visible in fully-enlightened CoCo VMs,
the paravisor filters out these flags and the guest Linux does not see them.
Throughout the Linux kernel, explicitly testing these flags has mostly been
eliminated in favor of the cc_platform_has() function, with the goal of
abstracting the differences between SEV-SNP and TDX. But the
cc_platform_has() abstraction also allows the Hyper-V paravisor configuration
to selectively enable aspects of CoCo VM functionality even when the CPUID
flags are not set. The exception is early boot memory setup on SEV-SNP, which
tests the CPUID SEV-SNP flag. But not having the flag in Hyper-V paravisor
mode VM achieves the desired effect or not running SEV-SNP specific early
boot memory setup.
* Device emulation. In paravisor mode, the Hyper-V paravisor provides
emulation of devices such as the IO-APIC and TPM. Because the emulation
happens in the paravisor in the guest context (instead of the hypervisor/VMM
context), MMIO accesses to these devices must be encrypted references instead
of the decrypted references that would be used in a fully-enlightened CoCo
VM. The __ioremap_caller() function has been enhanced to make a callback to
check whether a particular address range should be treated as encrypted
(private). See the "is_private_mmio" callback.
* Encrypt/decrypt memory transitions. In a CoCo VM, transitioning guest
memory between encrypted and decrypted requires coordinating with the
hypervisor/VMM. This is done via callbacks invoked from
__set_memory_enc_pgtable(). In fully-enlightened mode, the normal SEV-SNP and
TDX implementations of these callbacks are used. In paravisor mode, a Hyper-V
specific set of callbacks is used. These callbacks invoke the paravisor so
that the paravisor can coordinate the transitions and inform the hypervisor
as necessary. See hv_vtom_init() where these callback are set up.
* Interrupt injection. In fully enlightened mode, a malicious hypervisor
could inject interrupts into the guest OS at times that violate x86/x64
architectural rules. For full protection, the guest OS should include
enlightenments that use the interrupt injection management features provided
by CoCo-capable processors. In paravisor mode, the paravisor mediates
interrupt injection into the guest OS, and ensures that the guest OS only
sees interrupts that are "legal". The paravisor uses the interrupt injection
management features provided by the CoCo-capable physical processor, thereby
masking these complexities from the guest OS.
Hyper-V Hypercalls
------------------
When in fully-enlightened mode, hypercalls made by the Linux guest are routed
directly to the hypervisor, just as in a non-CoCo VM. But in paravisor mode,
normal hypercalls trap to the paravisor first, which may in turn invoke the
hypervisor. But the paravisor is idiosyncratic in this regard, and a few
hypercalls made by the Linux guest must always be routed directly to the
hypervisor. These hypercall sites test for a paravisor being present, and use
a special invocation sequence. See hv_post_message(), for example.
Guest communication with Hyper-V
--------------------------------
Separate from the generic Linux kernel handling of memory encryption in Linux
CoCo VMs, Hyper-V has VMBus and VMBus devices that communicate using memory
shared between the Linux guest and the host. This shared memory must be
marked decrypted to enable communication. Furthermore, since the threat model
includes a compromised and potentially malicious host, the guest must guard
against leaking any unintended data to the host through this shared memory.
These Hyper-V and VMBus memory pages are marked as decrypted:
* VMBus monitor pages
* Synthetic interrupt controller (synic) related pages (unless supplied by
the paravisor)
* Per-cpu hypercall input and output pages (unless running with a paravisor)
* VMBus ring buffers. The direct mapping is marked decrypted in
__vmbus_establish_gpadl(). The secondary mapping created in
hv_ringbuffer_init() must also include the "decrypted" attribute.
When the guest writes data to memory that is shared with the host, it must
ensure that only the intended data is written. Padding or unused fields must
be initialized to zeros before copying into the shared memory so that random
kernel data is not inadvertently given to the host.
Similarly, when the guest reads memory that is shared with the host, it must
validate the data before acting on it so that a malicious host cannot induce
the guest to expose unintended data. Doing such validation can be tricky
because the host can modify the shared memory areas even while or after
validation is performed. For messages passed from the host to the guest in a
VMBus ring buffer, the length of the message is validated, and the message is
copied into a temporary (encrypted) buffer for further validation and
processing. The copying adds a small amount of overhead, but is the only way
to protect against a malicious host. See hv_pkt_iter_first().
Many drivers for VMBus devices have been "hardened" by adding code to fully
validate messages received over VMBus, instead of assuming that Hyper-V is
acting cooperatively. Such drivers are marked as "allowed_in_isolated" in the
vmbus_devs[] table. Other drivers for VMBus devices that are not needed in a
CoCo VM have not been hardened, and they are not allowed to load in a CoCo
VM. See vmbus_is_valid_offer() where such devices are excluded.
Two VMBus devices depend on the Hyper-V host to do DMA data transfers:
storvsc for disk I/O and netvsc for network I/O. storvsc uses the normal
Linux kernel DMA APIs, and so bounce buffering through decrypted swiotlb
memory is done implicitly. netvsc has two modes for data transfers. The first
mode goes through send and receive buffer space that is explicitly allocated
by the netvsc driver, and is used for most smaller packets. These send and
receive buffers are marked decrypted by __vmbus_establish_gpadl(). Because
the netvsc driver explicitly copies packets to/from these buffers, the
equivalent of bounce buffering between encrypted and decrypted memory is
already part of the data path. The second mode uses the normal Linux kernel
DMA APIs, and is bounce buffered through swiotlb memory implicitly like in
storvsc.
Finally, the VMBus virtual PCI driver needs special handling in a CoCo VM.
Linux PCI device drivers access PCI config space using standard APIs provided
by the Linux PCI subsystem. On Hyper-V, these functions directly access MMIO
space, and the access traps to Hyper-V for emulation. But in CoCo VMs, memory
encryption prevents Hyper-V from reading the guest instruction stream to
emulate the access. So in a CoCo VM, these functions must make a hypercall
with arguments explicitly describing the access. See
_hv_pcifront_read_config() and _hv_pcifront_write_config() and the
"use_calls" flag indicating to use hypercalls.
load_unaligned_zeropad()
------------------------
When transitioning memory between encrypted and decrypted, the caller of
set_memory_encrypted() or set_memory_decrypted() is responsible for ensuring
the memory isn't in use and isn't referenced while the transition is in
progress. The transition has multiple steps, and includes interaction with
the Hyper-V host. The memory is in an inconsistent state until all steps are
complete. A reference while the state is inconsistent could result in an
exception that can't be cleanly fixed up.
However, the kernel load_unaligned_zeropad() mechanism may make stray
references that can't be prevented by the caller of set_memory_encrypted() or
set_memory_decrypted(), so there's specific code in the #VC or #VE exception
handler to fixup this case. But a CoCo VM running on Hyper-V may be
configured to run with a paravisor, with the #VC or #VE exception routed to
the paravisor. There's no architectural way to forward the exceptions back to
the guest kernel, and in such a case, the load_unaligned_zeropad() fixup code
in the #VC/#VE handlers doesn't run.
To avoid this problem, the Hyper-V specific functions for notifying the
hypervisor of the transition mark pages as "not present" while a transition
is in progress. If load_unaligned_zeropad() causes a stray reference, a
normal page fault is generated instead of #VC or #VE, and the page-fault-
based handlers for load_unaligned_zeropad() fixup the reference. When the
encrypted/decrypted transition is complete, the pages are marked as "present"
again. See hv_vtom_clear_present() and hv_vtom_set_host_visibility().
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Hyper-V CoCo VM 개요
1-13Hyper-V는 Confidential Computing(CoCo) VM인 Linux guest를 만들고 실행할 수 있습니다. 이 VM은 물리 processor와 협력해 hypervisor 또는 VMM이 침해되어 악의적으로 동작하더라도 VM memory data의 기밀성과 무결성을 더 강하게 보호합니다.
Hyper-V CoCo VM은 `Documentation/security/snp-tdx-threat-model.rst`에 설명된 일반 CoCo VM threat model과 보안 목표를 공유합니다. Linux의 Hyper-V 전용 코드는 CoCo VM을 `isolated VM` 또는 `isolation VM`이라고 부릅니다.
.. SPDX-License-Identifier: GPL-2.0
Confidential Computing VMs
==========================
Hyper-V can create and run Linux guests that are Confidential Computing
(CoCo) VMs. Such VMs cooperate with the physical processor to better protect
the confidentiality and integrity of data in the VM's memory, even in the
face of a hypervisor/VMM that has been compromised and may behave maliciously.
CoCo VMs on Hyper-V share the generic CoCo VM threat model and security
objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
"isolation VMs".
구성 요소와 하드웨어 요구 사항
14-34Linux Hyper-V CoCo VM에는 CoCo VM을 지원하는 물리 processor, CoCo VM 지원 Windows/Hyper-V, CoCo guest로 동작할 수 있는 Linux가 모두 필요합니다.
AMD platform은 SEV-SNP processor가 필요합니다. Hyper-V는 AMD SME, SEV 또는 SEV-ES 암호화를 사용하는 guest VM을 실행하지 않으며, 이 기술만으로는 Hyper-V CoCo VM에 충분하지 않습니다. Intel platform은 TDX processor가 필요합니다.
VM 생성 시 Hyper-V에 `Isolated VM` 속성을 지정해야 합니다. 생성된 뒤에는 CoCo VM과 일반 VM 사이를 어느 방향으로도 전환할 수 없습니다.
하드웨어부터 guest OS까지 세 계층이 모두 지원해야 합니다.
A Linux CoCo VM on Hyper-V requires the cooperation and interaction of the
following:
* Physical hardware with a processor that supports CoCo VMs
* The hardware runs a version of Windows/Hyper-V with support for CoCo VMs
* The VM runs a version of Linux that supports being a CoCo VM
The physical hardware requirements are as follows:
* AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
SEV, or SEV-ES encryption, and such encryption is not sufficient for a CoCo
VM on Hyper-V.
* Intel processor with TDX
To create a CoCo VM, the "Isolated VM" attribute must be specified to Hyper-V
when the VM is created. A VM cannot be changed from a CoCo VM to a normal VM,
or vice versa, after it is created.
운영 모드
35-47Hyper-V CoCo VM은 fully-enlightened mode와 paravisor mode 중 하나로 실행됩니다. 모드는 VM 생성 시 선택하며 VM의 수명 동안 바꿀 수 없습니다.
Fully-enlightened mode에서는 guest OS가 CoCo VM 실행의 모든 측면을 이해하고 직접 관리합니다. Paravisor mode에서는 guest와 host 사이의 paravisor layer가 일부 필수 동작을 제공하므로 guest OS에 필요한 CoCo enlightenment가 더 적습니다.
CoCo 책임을 guest와 paravisor가 나누는 방식입니다.
Operational Modes
-----------------
Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
created and cannot be changed during the life of the VM.
* Fully-enlightened mode. In this mode, the guest operating system is
enlightened to understand and manage all aspects of running as a CoCo VM.
* Paravisor mode. In this mode, a paravisor layer between the guest and the
host provides some operations needed to run as a CoCo VM. The guest operating
system can have fewer CoCo enlightenments than is required in the
fully-enlightened case.
Paravisor 기능 범위와 신뢰 경계
48-75두 모드는 guest enlightenment 정도를 나타내는 연속선의 양 끝으로 생각할 수 있습니다. Fully-enlightened mode가 한쪽 끝이고, 완전한 paravisor 구현은 memory encryption을 전혀 모르는 일반 guest OS도 실행할 수 있도록 모든 CoCo 기능을 맡는 반대쪽 끝입니다.
Hyper-V paravisor는 그 중간에 있습니다. 일부 CoCo 기능은 paravisor가 담당하고 나머지는 guest OS가 이해해야 합니다. Paravisor가 제공할 기능을 표준적으로 열거하거나 guest가 질의하는 표준 mechanism이 없으므로 제공 기능에 대한 지식은 guest OS에 hard-code됩니다.
Hyper-V paravisor는 virtual TPM 같은 제한된 서비스를 목표로 하는 Coconut project와 비슷하지만 현재 Coconut 구상보다 더 많은 CoCo 측면을 처리합니다. 원문은 Coconut project를 `https://github.com/coconut-svsm/svsm`에 연결합니다.
CoCo threat model에서 paravisor는 guest security domain 안에 있고 guest OS가 신뢰해야 합니다. 반대로 hypervisor/VMM은 악성 guest를 방어하듯 잠재적으로 악성인 paravisor에서도 자신을 보호해야 합니다.
Guest enlightenment와 paravisor 서비스의 상대적 크기입니다.
Conceptually, fully-enlightened mode and paravisor mode may be treated as
points on a spectrum spanning the degree of guest enlightenment needed to run
as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A full
implementation of paravisor mode is the other end of the spectrum, where all
aspects of running as a CoCo VM are handled by the paravisor, and a normal
guest OS with no knowledge of memory encryption or other aspects of CoCo VMs
can run successfully. However, the Hyper-V implementation of paravisor mode
does not go this far, and is somewhere in the middle of the spectrum. Some
aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
must be enlightened for other aspects. Unfortunately, there is no
standardized enumeration of feature/functions that might be provided in the
paravisor, and there is no standardized mechanism for a guest OS to query the
paravisor for the feature/functions it provides. The understanding of what
the paravisor provides is hard-coded in the guest OS.
Paravisor mode has similarities to the `Coconut project`_, which aims to provide
a limited paravisor to provide services to the guest such as a virtual TPM.
However, the Hyper-V paravisor generally handles more aspects of CoCo VMs
than is currently envisioned for Coconut, and so is further toward the "no
guest enlightenments required" end of the spectrum.
.. _Coconut project: https://github.com/coconut-svsm/svsm
In the CoCo VM threat model, the paravisor is in the guest security domain
and must be trusted by the guest OS. By implication, the hypervisor/VMM must
protect itself against a potentially malicious paravisor just like it
protects against a potentially malicious guest.
SEV-SNP·TDX별 모드 구현
76-97AMD SEV-SNP의 fully-enlightened mode에서는 guest OS가 VMPL 0에서 실행되어 guest context를 완전히 제어합니다. Paravisor mode에서는 paravisor가 VMPL 0, guest OS가 VMPL 2에서 실행되며 privileged operation은 guest가 paravisor를 호출해야 합니다.
SEV-SNP paravisor mode의 guest OS는 architecture가 정의한 virtual Top Of Memory(vTOM) mode로 동작합니다. vTOM은 paravisor를 사용할 때 guest의 memory encryption 관리를 단순화합니다.
Intel TDX의 fully-enlightened mode에서는 guest OS가 L1 VM에서 실행됩니다. Paravisor mode는 TD partitioning을 사용해 paravisor를 L1 VM에, guest OS를 nested L2 VM에 둡니다.
Hyper-V는 CoCo mode를 설명하는 synthetic MSR을 guest에 제공합니다. 이 MSR은 underlying processor가 AMD SEV-SNP인지 Intel TDX인지와 paravisor 사용 여부를 표시하므로 하나의 kernel image가 두 architecture와 두 mode 모두에서 boot·실행될 수 있습니다.
Fully-enlightened와 paravisor mode의 guest 위치입니다.
The hardware architectural approach to fully-enlightened vs. paravisor mode
varies depending on the underlying processor.
* With AMD SEV-SNP processors, in fully-enlightened mode the guest OS runs in
VMPL 0 and has full control of the guest context. In paravisor mode, the
guest OS runs in VMPL 2 and the paravisor runs in VMPL 0. The paravisor
running in VMPL 0 has privileges that the guest OS in VMPL 2 does not have.
Certain operations require the guest to invoke the paravisor. Furthermore, in
paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
as defined by the SEV-SNP architecture. This mode simplifies guest management
of memory encryption when a paravisor is used.
* With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
L1 VM. In paravisor mode, TD partitioning is used. The paravisor runs in the
L1 VM, and the guest OS runs in a nested L2 VM.
Hyper-V exposes a synthetic MSR to guests that describes the CoCo mode. This
MSR indicates if the underlying processor uses AMD SEV-SNP or Intel TDX, and
whether a paravisor is being used. It is straightforward to build a single
kernel image that can boot and run properly on either architecture, and in
either mode.
Paravisor 효과: 초기 guest memory
98-109Paravisor mode로 새 VM을 만들면 paravisor가 먼저 실행되어 guest physical memory를 encrypted 상태로 설정합니다.
Guest Linux는 일반 memory initialization을 수행하되 필요한 범위만 명시적으로 decrypted(shared)로 표시합니다. 따라서 fully-enlightened AMD SEV-SNP에서 특히 까다로운 early-boot memory setup 단계는 paravisor mode Linux가 수행하지 않습니다.
초기 암호화 책임이 guest보다 먼저 실행되는 paravisor로 이동합니다.
Paravisor Effects
-----------------
Running in paravisor mode affects the following areas of generic Linux kernel
CoCo VM functionality:
* Initial guest memory setup. When a new VM is created in paravisor mode, the
paravisor runs first and sets up the guest physical memory as encrypted. The
guest Linux does normal memory initialization, except for explicitly marking
appropriate ranges as decrypted (shared). In paravisor mode, Linux does not
perform the early boot memory setup steps that are particularly tricky with
AMD SEV-SNP in fully-enlightened mode.
#VC/#VE와 CPUID 추상화
110-129Paravisor mode에서 Hyper-V는 `#VC`와 `#VE` exception을 각각 VMPL 0과 L1 VM으로 보내 guest Linux에는 전달하지 않습니다. 따라서 guest Linux의 exception handler는 실행되지 않으며 paravisor mode에 필요한 enlightenment도 아닙니다.
AMD SEV-SNP와 Intel TDX는 각각 hardware 지원을 나타내는 CPUID flag를 guest에 제공합니다. Fully-enlightened VM에서는 보이지만 paravisor가 이 flag들을 필터링하므로 guest Linux는 볼 수 없습니다.
Linux는 두 architecture 차이를 추상화하기 위해 대부분의 직접 flag 검사 대신 `cc_platform_has()`를 사용합니다. 이 추상화로 CPUID flag가 없어도 Hyper-V paravisor 구성이 선택한 CoCo 기능을 켤 수 있습니다.
예외는 SEV-SNP early-boot memory setup입니다. 이 코드는 SEV-SNP CPUID flag를 직접 검사하지만 paravisor mode에서는 flag가 없으므로 의도대로 SEV-SNP 전용 초기 설정을 실행하지 않습니다.
Guest Linux가 직접 처리하지 않는 항목입니다.
* #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
CoCo VM to route #VC and #VE exceptions to VMPL 0 and the L1 VM,
respectively, and not the guest Linux. Consequently, these exception handlers
do not run in the guest Linux and are not a required enlightenment for a
Linux guest in paravisor mode.
* CPUID flags. Both AMD SEV-SNP and Intel TDX provide a CPUID flag in the
guest indicating that the VM is operating with the respective hardware
support. While these CPUID flags are visible in fully-enlightened CoCo VMs,
the paravisor filters out these flags and the guest Linux does not see them.
Throughout the Linux kernel, explicitly testing these flags has mostly been
eliminated in favor of the cc_platform_has() function, with the goal of
abstracting the differences between SEV-SNP and TDX. But the
cc_platform_has() abstraction also allows the Hyper-V paravisor configuration
to selectively enable aspects of CoCo VM functionality even when the CPUID
flags are not set. The exception is early boot memory setup on SEV-SNP, which
tests the CPUID SEV-SNP flag. But not having the flag in Hyper-V paravisor
mode VM achieves the desired effect or not running SEV-SNP specific early
boot memory setup.
Device emulation과 memory transition
130-147Paravisor mode에서 Hyper-V paravisor는 IO-APIC과 TPM 같은 device를 guest context 안에서 emulate합니다. Hypervisor/VMM context에서 emulate하는 fully-enlightened VM과 달리 이 device의 MMIO 접근은 decrypted reference가 아니라 encrypted(private) reference여야 합니다.
`__ioremap_caller()`는 특정 address range를 encrypted로 취급할지 확인하는 callback을 호출하도록 확장됐습니다. 관련 callback은 `is_private_mmio`입니다.
Guest memory를 encrypted와 decrypted 사이에서 전환하려면 hypervisor/VMM과 coordination해야 하며 `__set_memory_enc_pgtable()`이 호출하는 callback으로 수행합니다. Fully-enlightened mode는 일반 SEV-SNP·TDX callback을 사용합니다.
Paravisor mode는 Hyper-V 전용 callback으로 paravisor를 호출하고, paravisor가 전환을 조정해 필요하면 hypervisor에 알립니다. Callback 설정 위치는 `hv_vtom_init()`입니다.
MMIO와 memory visibility callback의 차이입니다.
* Device emulation. In paravisor mode, the Hyper-V paravisor provides
emulation of devices such as the IO-APIC and TPM. Because the emulation
happens in the paravisor in the guest context (instead of the hypervisor/VMM
context), MMIO accesses to these devices must be encrypted references instead
of the decrypted references that would be used in a fully-enlightened CoCo
VM. The __ioremap_caller() function has been enhanced to make a callback to
check whether a particular address range should be treated as encrypted
(private). See the "is_private_mmio" callback.
* Encrypt/decrypt memory transitions. In a CoCo VM, transitioning guest
memory between encrypted and decrypted requires coordinating with the
hypervisor/VMM. This is done via callbacks invoked from
__set_memory_enc_pgtable(). In fully-enlightened mode, the normal SEV-SNP and
TDX implementations of these callbacks are used. In paravisor mode, a Hyper-V
specific set of callbacks is used. These callbacks invoke the paravisor so
that the paravisor can coordinate the transitions and inform the hypervisor
as necessary. See hv_vtom_init() where these callback are set up.
Interrupt injection 중재
148-157Fully-enlightened mode에서는 악성 hypervisor가 x86/x64 architecture 규칙을 위반하는 시점에 guest OS로 interrupt를 주입할 수 있습니다. 완전한 보호를 위해 guest OS가 CoCo processor의 interrupt-injection management 기능을 사용하는 enlightenment를 구현해야 합니다.
Paravisor mode에서는 paravisor가 guest OS로 들어가는 interrupt injection을 중재해 합법적인 interrupt만 보이게 합니다. Paravisor가 물리 processor의 관리 기능을 사용하므로 guest OS에서는 복잡성이 감춰집니다.
Host 요청을 architecture 규칙에 맞는 guest interrupt로 제한합니다.
* Interrupt injection. In fully enlightened mode, a malicious hypervisor
could inject interrupts into the guest OS at times that violate x86/x64
architectural rules. For full protection, the guest OS should include
enlightenments that use the interrupt injection management features provided
by CoCo-capable processors. In paravisor mode, the paravisor mediates
interrupt injection into the guest OS, and ensures that the guest OS only
sees interrupts that are "legal". The paravisor uses the interrupt injection
management features provided by the CoCo-capable physical processor, thereby
masking these complexities from the guest OS.
Hyper-V hypercall 경로
158-167Fully-enlightened mode의 Linux guest hypercall은 일반 VM처럼 hypervisor로 직접 전달됩니다. Paravisor mode의 정상 hypercall은 먼저 paravisor에 trap되고 paravisor가 필요하면 hypervisor를 호출합니다.
다만 일부 Linux guest hypercall은 paravisor가 있어도 항상 hypervisor로 직접 보내야 합니다. 해당 호출 지점은 paravisor 존재 여부를 검사하고 특별한 invocation sequence를 사용하며 `hv_post_message()`가 예입니다.
Mode와 호출 종류에 따라 paravisor를 거치거나 우회합니다.
Hyper-V Hypercalls
------------------
When in fully-enlightened mode, hypercalls made by the Linux guest are routed
directly to the hypervisor, just as in a non-CoCo VM. But in paravisor mode,
normal hypercalls trap to the paravisor first, which may in turn invoke the
hypervisor. But the paravisor is idiosyncratic in this regard, and a few
hypercalls made by the Linux guest must always be routed directly to the
hypervisor. These hypercall sites test for a paravisor being present, and use
a special invocation sequence. See hv_post_message(), for example.
Shared memory 쓰기·읽기 방어
190-204Guest가 host와 공유한 memory에 data를 쓸 때는 의도한 data만 기록해야 합니다. Padding과 unused field는 shared memory로 복사하기 전에 0으로 초기화해 임의의 kernel data가 host에 노출되지 않게 합니다.
Guest가 shared memory를 읽을 때는 악성 host가 의도하지 않은 data 노출을 유도하지 못하도록 사용 전에 검증해야 합니다. Host는 검증 중이나 직후에도 shared area를 바꿀 수 있어 단순한 in-place 검사는 충분하지 않습니다.
VMBus ring buffer의 host-to-guest message는 먼저 길이를 검사한 뒤 임시 encrypted buffer로 복사하고 추가 검증·처리를 수행합니다. 작은 overhead가 생기지만 악성 host의 동시 변경을 막는 유일한 방법입니다. 관련 코드는 `hv_pkt_iter_first()`입니다.
Shared buffer를 직접 신뢰하지 않고 private snapshot에서 처리합니다.
Guest에서 host 방향과 host에서 guest 방향을 구분합니다.
When the guest writes data to memory that is shared with the host, it must
ensure that only the intended data is written. Padding or unused fields must
be initialized to zeros before copying into the shared memory so that random
kernel data is not inadvertently given to the host.
Similarly, when the guest reads memory that is shared with the host, it must
validate the data before acting on it so that a malicious host cannot induce
the guest to expose unintended data. Doing such validation can be tricky
because the host can modify the shared memory areas even while or after
validation is performed. For messages passed from the host to the guest in a
VMBus ring buffer, the length of the message is validated, and the message is
copied into a temporary (encrypted) buffer for further validation and
processing. The copying adds a small amount of overhead, but is the only way
to protect against a malicious host. See hv_pkt_iter_first().
VMBus driver hardening
205-211여러 VMBus device driver는 Hyper-V가 협력한다고 가정하지 않고 수신 message 전체를 검증하도록 hardening됐습니다. 이런 driver는 `vmbus_devs[]` table에서 `allowed_in_isolated`로 표시됩니다.
CoCo VM에 필요하지 않고 hardening하지 않은 VMBus driver는 CoCo VM에서 load할 수 없습니다. Device 제외 판단은 `vmbus_is_valid_offer()`에서 수행합니다.
Many drivers for VMBus devices have been "hardened" by adding code to fully
validate messages received over VMBus, instead of assuming that Hyper-V is
acting cooperatively. Such drivers are marked as "allowed_in_isolated" in the
vmbus_devs[] table. Other drivers for VMBus devices that are not needed in a
CoCo VM have not been hardened, and they are not allowed to load in a CoCo
VM. See vmbus_is_valid_offer() where such devices are excluded.
storvsc와 netvsc DMA
212-224Host가 DMA data transfer를 수행하는 VMBus device는 disk I/O의 `storvsc`와 network I/O의 `netvsc` 두 개입니다.
`storvsc`는 일반 Linux DMA API를 사용하므로 decrypted `swiotlb` memory를 통한 bounce buffering이 자동으로 적용됩니다.
`netvsc`의 첫 번째 mode는 driver가 명시적으로 할당한 send·receive buffer를 사용하며 주로 작은 packet을 처리합니다. 이 buffer는 `__vmbus_establish_gpadl()`이 decrypted로 표시하고 driver가 packet을 명시적으로 복사하므로 encrypted·decrypted memory 사이 bounce buffering이 data path에 이미 포함됩니다.
두 번째 `netvsc` mode는 일반 Linux DMA API를 사용하므로 `storvsc`처럼 `swiotlb` memory를 통해 자동으로 bounce buffering됩니다.
Encrypted guest memory와 host-visible buffer 사이의 복사 방식입니다.
Two VMBus devices depend on the Hyper-V host to do DMA data transfers:
storvsc for disk I/O and netvsc for network I/O. storvsc uses the normal
Linux kernel DMA APIs, and so bounce buffering through decrypted swiotlb
memory is done implicitly. netvsc has two modes for data transfers. The first
mode goes through send and receive buffer space that is explicitly allocated
by the netvsc driver, and is used for most smaller packets. These send and
receive buffers are marked decrypted by __vmbus_establish_gpadl(). Because
the netvsc driver explicitly copies packets to/from these buffers, the
equivalent of bounce buffering between encrypted and decrypted memory is
already part of the data path. The second mode uses the normal Linux kernel
DMA APIs, and is bounce buffered through swiotlb memory implicitly like in
storvsc.
Virtual PCI config access
225-234VMBus virtual PCI driver는 CoCo VM에서 특별한 처리가 필요합니다. 일반 Linux PCI driver는 PCI subsystem의 표준 API로 config space에 접근하며 Hyper-V에서는 이 함수가 MMIO를 직접 접근해 trap을 일으키고 Hyper-V가 emulate합니다.
CoCo VM의 memory encryption은 Hyper-V가 guest instruction stream을 읽어 접근을 emulate하지 못하게 합니다. 따라서 CoCo VM에서는 접근 내용을 argument로 명시하는 hypercall을 사용해야 합니다.
관련 함수는 `_hv_pcifront_read_config()`와 `_hv_pcifront_write_config()`이며 `use_calls` flag가 hypercall 사용을 나타냅니다.
Instruction decoding 대신 명시적 hypercall ABI를 사용합니다.
Finally, the VMBus virtual PCI driver needs special handling in a CoCo VM.
Linux PCI device drivers access PCI config space using standard APIs provided
by the Linux PCI subsystem. On Hyper-V, these functions directly access MMIO
space, and the access traps to Hyper-V for emulation. But in CoCo VMs, memory
encryption prevents Hyper-V from reading the guest instruction stream to
emulate the access. So in a CoCo VM, these functions must make a hypercall
with arguments explicitly describing the access. See
_hv_pcifront_read_config() and _hv_pcifront_write_config() and the
"use_calls" flag indicating to use hypercalls.
load_unaligned_zeropad()와 memory 전환
235-260`set_memory_encrypted()` 또는 `set_memory_decrypted()` 호출자는 encrypted·decrypted 전환 중 memory가 사용되거나 참조되지 않게 보장해야 합니다. 전환은 Hyper-V host와 상호 작용하는 여러 단계로 구성되며 완료 전에는 memory state가 일관되지 않습니다.
불일치 상태에서 참조가 발생하면 깔끔하게 fixup할 수 없는 exception이 생길 수 있습니다. 그러나 kernel의 `load_unaligned_zeropad()`는 호출자가 막을 수 없는 stray reference를 만들 수 있어 일반 CoCo 구현은 `#VC` 또는 `#VE` handler에서 이 경우를 보정합니다.
Hyper-V paravisor mode에서는 `#VC`·`#VE`가 paravisor로 route되고 이를 guest kernel로 전달할 architecture mechanism이 없습니다. 따라서 guest의 `#VC/#VE` fixup code는 실행되지 않습니다.
이를 피하려고 Hyper-V 전용 transition notification 함수는 전환 중 page를 `not present`로 표시합니다. `load_unaligned_zeropad()`가 stray reference를 만들면 `#VC/#VE` 대신 일반 page fault가 발생하고 page-fault 기반 handler가 참조를 fixup합니다.
Encrypted/decrypted 전환이 끝나면 page를 다시 `present`로 표시합니다. 관련 함수는 `hv_vtom_clear_present()`와 `hv_vtom_set_host_visibility()`입니다.
전환 중 stray reference를 정상 page-fault 경로로 유도합니다.
load_unaligned_zeropad()
------------------------
When transitioning memory between encrypted and decrypted, the caller of
set_memory_encrypted() or set_memory_decrypted() is responsible for ensuring
the memory isn't in use and isn't referenced while the transition is in
progress. The transition has multiple steps, and includes interaction with
the Hyper-V host. The memory is in an inconsistent state until all steps are
complete. A reference while the state is inconsistent could result in an
exception that can't be cleanly fixed up.
However, the kernel load_unaligned_zeropad() mechanism may make stray
references that can't be prevented by the caller of set_memory_encrypted() or
set_memory_decrypted(), so there's specific code in the #VC or #VE exception
handler to fixup this case. But a CoCo VM running on Hyper-V may be
configured to run with a paravisor, with the #VC or #VE exception routed to
the paravisor. There's no architectural way to forward the exceptions back to
the guest kernel, and in such a case, the load_unaligned_zeropad() fixup code
in the #VC/#VE handlers doesn't run.
To avoid this problem, the Hyper-V specific functions for notifying the
hypervisor of the transition mark pages as "not present" while a transition
is in progress. If load_unaligned_zeropad() causes a stray reference, a
normal page fault is generated instead of #VC or #VE, and the page-fault-
based handlers for load_unaligned_zeropad() fixup the reference. When the
encrypted/decrypted transition is complete, the pages are marked as "present"
again. See hv_vtom_clear_present() and hv_vtom_set_host_visibility().
요약·해설
coco.rst:1-260Hyper-V CoCo 지원의 중심은 hardware encryption 자체보다 책임 경계를 정확히 나누는 데 있습니다. Paravisor mode는 초기 memory·exception·interrupt 복잡성을 guest에서 가져가지만 guest가 신뢰해야 하는 코드가 됩니다. Host-visible VMBus memory는 쓰기 전 zeroing, 읽은 뒤 private copy 검증, DMA bounce buffering을 적용해야 하며 visibility transition은 page-present 상태를 이용해 예기치 않은 참조도 복구 가능한 fault로 바꿉니다.