linux-kernel - RE: [PATCHv4 11/30] x86/tdx: Handle in-kernel MMIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c536496125844ccaca50aa0740c8585@AcuMS.aculab.com>
Date:   Fri, 25 Feb 2022 03:10:39 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Dave Hansen' <dave.hansen@...el.com>,
        "'Kirill A. Shutemov'" <kirill.shutemov@...ux.intel.com>,
        "'tglx@...utronix.de'" <tglx@...utronix.de>,
        "'mingo@...hat.com'" <mingo@...hat.com>,
        "'bp@...en8.de'" <bp@...en8.de>,
        "'luto@...nel.org'" <luto@...nel.org>,
        "'peterz@...radead.org'" <peterz@...radead.org>
CC:     "'sathyanarayanan.kuppuswamy@...ux.intel.com'" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "'aarcange@...hat.com'" <aarcange@...hat.com>,
        "'ak@...ux.intel.com'" <ak@...ux.intel.com>,
        "'dan.j.williams@...el.com'" <dan.j.williams@...el.com>,
        "'david@...hat.com'" <david@...hat.com>,
        "'hpa@...or.com'" <hpa@...or.com>,
        "'jgross@...e.com'" <jgross@...e.com>,
        "'jmattson@...gle.com'" <jmattson@...gle.com>,
        "'joro@...tes.org'" <joro@...tes.org>,
        "'jpoimboe@...hat.com'" <jpoimboe@...hat.com>,
        "'knsathya@...nel.org'" <knsathya@...nel.org>,
        "'pbonzini@...hat.com'" <pbonzini@...hat.com>,
        "'sdeep@...are.com'" <sdeep@...are.com>,
        "'seanjc@...gle.com'" <seanjc@...gle.com>,
        "'tony.luck@...el.com'" <tony.luck@...el.com>,
        "'vkuznets@...hat.com'" <vkuznets@...hat.com>,
        "'wanpengli@...cent.com'" <wanpengli@...cent.com>,
        "'thomas.lendacky@....com'" <thomas.lendacky@....com>,
        "'brijesh.singh@....com'" <brijesh.singh@....com>,
        "'x86@...nel.org'" <x86@...nel.org>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCHv4 11/30] x86/tdx: Handle in-kernel MMIO

From: David Laight
> Sent: 25 February 2022 02:23
> 
> From: Dave Hansen
> > Sent: 24 February 2022 20:12
> ...
> > === Limitations of this approach ===
> >
> > > MMIO addresses can be used with any CPU instruction that accesses
> > > memory. Address only MMIO accesses done via io.h helpers, such as
> > > 'readl()' or 'writeq()'.
> >
> > Any CPU instruction that accesses memory can also be used to access
> > MMIO.  However, by convention, MMIO access are typically performed via
> > io.h helpers such as 'readl()' or 'writeq()'.
> >
> > > readX()/writeX() helpers limit the range of instructions which can trigger
> > > MMIO. It makes MMIO instruction emulation feasible. Raw access to a MMIO
> > > region allows the compiler to generate whatever instruction it wants.
> > > Supporting all possible instructions is a task of a different scope.
> >
> > The io.h helpers intentionally use a limited set of instructions when
> > accessing MMIO.  This known, limited set of instructions makes MMIO
> > instruction decoding and emulation feasible in KVM hosts and SEV guests
> > today.
> >
> > MMIO accesses are performed without the io.h helpers are at the mercy of
> > the compiler.  Compilers can and will generate a much more broad set of
> > instructions which can not practically be decoded and emulated.  TDX
> > guests will oops if they encounter one of these decoding failures.
> >
> > This means that TDX guests *must* use the io.h helpers to access MMIO.
> >
> > This requirement is not new.  Both KVM hosts and AMD SEV guests have the
> > same limitations on MMIO access.
> 
> Am I reading the last sentence correctly?
> Normally (on x86 at least) a driver can mmap() PCIe addresses directly
> into a user process.
> This lets a user process directly issue PCIe read/write bus cycles.
> These can be any instructions at all.
> I don't think we've had any issues doing that in normal VMs.

Actually we won't have been exposing PCIe devices to VMs.

> Or is this emulation only applying to specific PCIe slaves?
> 
> 	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)