lkml.org 
[lkml]   [2022]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCHv4 3/3] x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page
    From
    On 6/14/22 05:01, Kirill A. Shutemov wrote:
    > 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 VMM may configure
    > it to trigger #VE.
    >
    > Kernel assumes that #VE on a shared page is 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 fail them.
    > load_unaligned_zeropad() will recover using exception fixups.
    >
    > The issue was discovered by analysis. It was not triggered during the
    > testing.
    >
    > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    > ---
    > arch/x86/coco/tdx/tdx.c | 15 ++++++++++++++-
    > 1 file changed, 14 insertions(+), 1 deletion(-)
    >
    > diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
    > index 7d6d484a6d28..3bcaf2170ede 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 suppose to be naturally aligned and therefore never
    > + * cross a page boundary. Seeing split page accesses indicates a bug
    > + * or load_unaligned_zeropad() that steps into unmapped shared page.

    Isn't this "unmapped" thing a rather superfluous implementation detail?

    For the guest, it just needs to know that it *CAN* #VE on access to MMIO
    and that it needs to be prepared. The fact that MMIO is implemented
    with TDX shared memory *AND* that "unmapped shared pages" can cause
    #VE's seems like too much detail.

    Also, is this all precise? Are literal unmapped shared pages the *ONLY*
    thing that a hypervisor can do do case a #VE? What about, say, reserved
    bits being set in a shared EPT entry?

    I was thinking a comment like this might be better:

    > /*
    > * 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.
    > */


    \
     
     \ /
      Last update: 2022-06-15 20:40    [W:3.662 / U:0.840 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site