linux-kernel - Re: [PATCH v6 0/6] x86/tdx: Allow MMIO instructions from userspace

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: <d3895e03-bdfc-4f2a-a1c4-b2c95a098fb5@intel.com>
Date: Wed, 11 Sep 2024 08:38:15 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <seanjc@...gle.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 9/6/24 14:13, Sean Christopherson wrote:
> 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.

I think by "guest kernel" you really mean "x86 maintainers".  Thanks for
throwing us under the bus, Sean. ;)

I do agree with you, though.  In the process of taking the VMM out of
the TCB, confidential computing has to fill the gap with _something_ and
that something is usually arch-specific code in the guest kernel.

By dragging the KVM folks in here, I was less asking what KVM does per
se and more asking for some advice from the experienced VMM folks.

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

Do you have a link for that AVX discussion?  I searched a bit but came
up empty.

The slippery slope is precisely what I'm worried about.  I suspect the
AVX instructions are a combination of compilers that are increasingly
happy to spit out AVX and users who just want to use whatever the
compiler spits out on "pointers" in their apps that just happen to be
pointed at MMIO.

But before we start digging in to avoid the slippery slope, we really do
need to know more about the friction.  Who are we causing it for and how
bad is it for them?