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
| ||
|
Message-ID: <ZttwkLP74TrQgVtL@google.com> Date: Fri, 6 Sep 2024 14:13:52 -0700 From: Sean Christopherson <seanjc@...gle.com> To: Dave Hansen <dave.hansen@...el.com> Cc: Alexey Gladkov <legion@...nel.org>, linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Andrew Morton <akpm@...ux-foundation.org>, Yuan Yao <yuan.yao@...el.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, Yuntao Wang <ytcoode@...il.com>, Kai Huang <kai.huang@...el.com>, Baoquan He <bhe@...hat.com>, Oleg Nesterov <oleg@...hat.com>, cho@...rosoft.com, decui@...rosoft.com, John.Starks@...rosoft.com, Paolo Bonzini <pbonzini@...hat.com> Subject: Re: [PATCH v6 0/6] x86/tdx: Allow MMIO instructions from userspace On Fri, Sep 06, 2024, Dave Hansen wrote: > On 9/6/24 04:49, Alexey Gladkov wrote: > > Currently, MMIO inside the TDX guest is allowed from kernel space and access > > from userspace is denied. This becomes a problem when working with virtual > > devices in userspace. > > Kernel MMIO and User MMIO are very different beasts. > > The kernel MMIO instructions are trusted and can be constrained to use a > very limited number of instructions that match the kernel's limited > instruction decoding capability. > > Userspace is not constrained in that way. > > TDX also doesn't have the option of having the VMM deal with the > instruction emulation. > > Before we start down this road, I'd really want to hear from the KVM > folks that having the kernel decode arbitrary user instructions is the > way we want to go. That's an x86 kernel decision, not a KVM decision. KVM cares if the guest kernel has delegated certain permissions to userspace, which is why emulated MMIO is preferred over hypercalls; the fact that userspace can access an MMIO region communicates to KVM that the guest kernel has granted userspace the necessary permissions (by mapping the MMIO region into the user page tables). But whether or not a particular user/application is trusted by the guest kernel is firmly out of scope for KVM. KVM's responsibility is to not undermine the guest kernel's security/trust model, but KVM doesn't define that model. Ditto for what behavior is supported/allowed. The kernel could choose to disallow userspace MMIO entirely, limit what instructions are supported, etc, in the name of security, simplicity, or whatever. Doing so would likely cause friction with folks that want to run their workloads in an SNP/TDX VM, but that friction is very much with the guest kernel, not with KVM. FWIW, emulating MMIO that isn't controlled by the kernel gets to be a bit of a slippery slope, e.g. there are KVM patches on the list to support emulating AVX instructions[*]. But, a major use case of any hypervisor is to lift-and-shift workloads, and so KVM users, developers, and maintainers are quite motivated to ensure that anything that works on bare metal also works on KVM.
Powered by blists - more mailing lists