diff options
| author |   Kirill A. Shutemov <kirill.shutemov@linux.intel.com> | 2022-06-14 15:01:35 +0300 |
|---|---|---|
| committer |   Dave Hansen <dave.hansen@linux.intel.com> | 2022-06-17 15:37:33 -0700 |
| commit | 1e7769653b06b56b7ea7d56911d2d5b2957750cd (patch) | |
| tree | 25a3810999acb293a056132330d6c3b872fb850b /arch/x86/coco/tdx/tdx.c | |
| parent | x86/tdx: Clarify RIP adjustments in #VE handler (diff) | |
| download | linux-dev-1e7769653b06b56b7ea7d56911d2d5b2957750cd.tar.xz linux-dev-1e7769653b06b56b7ea7d56911d2d5b2957750cd.zip | |
x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page
load_unaligned_zeropad() can lead to unwanted loads across page boundaries.
The unwanted loads are typically harmless. But, they might be made to
totally unrelated or even unmapped memory. load_unaligned_zeropad()
relies on exception fixup (#PF, #GP and now #VE) to recover from these
unwanted loads.
In TDX guests, the second page can be shared page and a VMM may configure
it to trigger #VE.
The kernel assumes that #VE on a shared page is an MMIO access and tries to
decode instruction to handle it. In case of load_unaligned_zeropad() it
may result in confusion as it is not MMIO access.
Fix it by detecting split page MMIO accesses and failing them.
load_unaligned_zeropad() will recover using exception fixups.
The issue was discovered by analysis and reproduced artificially. It was
not triggered during testing.
[ dhansen: fix up changelogs and comments for grammar and clarity,
plus incorporate Kirill's off-by-one fix]
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lkml.kernel.org/r/20220614120135.14812-4-kirill.shutemov@linux.intel.com
Diffstat (limited to '')
| -rw-r--r-- | arch/x86/coco/tdx/tdx.c | 15 |
1 files changed, 14 insertions, 1 deletions
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index c8d44f463283..928dcf7a20d9 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -333,8 +333,8 @@ static bool mmio_write(int size, unsigned long addr, unsigned long val) static int handle_mmio(struct pt_regs *regs, struct ve_info *ve) { + unsigned long *reg, val, vaddr; char buffer[MAX_INSN_SIZE]; - unsigned long *reg, val; struct insn insn = {}; enum mmio_type mmio; int size, extend_size; @@ -360,6 +360,19 @@ static int handle_mmio(struct pt_regs *regs, struct ve_info *ve) return -EINVAL; } + /* + * Reject EPT violation #VEs that split pages. + * + * MMIO accesses are supposed to be naturally aligned and therefore + * never cross page boundaries. Seeing split page accesses indicates + * a bug or a load_unaligned_zeropad() that stepped into an MMIO page. + * + * load_unaligned_zeropad() will recover using exception fixups. + */ + vaddr = (unsigned long)insn_get_addr_ref(&insn, regs); + if (vaddr / PAGE_SIZE != (vaddr + size - 1) / PAGE_SIZE) + return -EFAULT; + /* Handle writes first */ switch (mmio) { case MMIO_WRITE: |