linux-kernel - RE: [EXTERNAL] Re: [PATCH] x86/tdx: Generate SIGBUS on userspace 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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <DS0PR21MB3863B0D93D5F6D8CBE83931BA5C72@DS0PR21MB3863.namprd21.prod.outlook.com>
Date: Tue, 11 Jun 2024 17:17:03 +0000
From: Chris Oo <cho@...rosoft.com>
To: Dave Hansen <dave.hansen@...el.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>, "H. Peter
 Anvin" <hpa@...or.com>
CC: "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Dexuan Cui
	<decui@...rosoft.com>, John Starks <John.Starks@...rosoft.com>
Subject: RE: [EXTERNAL] Re: [PATCH] x86/tdx: Generate SIGBUS on userspace MMIO

We have a usecase where we have device drivers in usermode using vfio that mmap regions of the address space to access device BARs. In this case, when the #VE handler cannot emulate mmio on behalf of usermode, we need the SIGBUS to know if we should retry the attempt via doing a write via the vfio file descriptor. 

We don't want to have every mmio go through the vfio file descriptor, because for pages that are actually backed by physical device's BAR we won't take a #VE and introduce a bunch of extra path length, but only if the host has chosen to emulate some page in that BAR. We also don't have any way of knowing which pages will cause a #VE because there's no way for the guest to query which pages the host has chosen to emulate accesses on. 

Chris

-----Original Message-----
From: Dave Hansen <dave.hansen@...el.com> 
Sent: Tuesday, June 11, 2024 9:16 AM
To: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>; Dave Hansen <dave.hansen@...ux.intel.com>; Thomas Gleixner <tglx@...utronix.de>; Ingo Molnar <mingo@...hat.com>; Borislav Petkov <bp@...en8.de>; x86@...nel.org; H. Peter Anvin <hpa@...or.com>
Cc: linux-coco@...ts.linux.dev; linux-kernel@...r.kernel.org; Chris Oo <cho@...rosoft.com>; Dexuan Cui <decui@...rosoft.com>; John Starks <John.Starks@...rosoft.com>
Subject: [EXTERNAL] Re: [PATCH] x86/tdx: Generate SIGBUS on userspace MMIO

[Some people who received this message don't often get email from dave.hansen@...el.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 6/10/24 06:55, Dave Hansen wrote:
>> Enlightened userspace may choose to handle MMIO on their own if the 
>> kernel does not emulate it.
>>
>> Handle the EPT_VIOLATION exit reason for userspace and deliver SIGBUS 
>> instead of SIGSEGV. SIGBUS is more appropriate for the MMIO situation.
> Is any userspace _actually_ doing this?  Sure, SIGBUS is more 
> appropriate but in practice unprepared userspace crashes either way.

I also can't help but wonder if there's a better way to do this.

Just thinking out loud.... Ideally, we'd reject creating a potentially troublesome VMA at mmap() time.  That's way better than, for instance, panic()'ing at some random place in the middle of program execution.

But I guess that's likely not possible because someone could be doing a VM_MIXEDMAP VMA that only has normal private pages and never _actually_ needs or has a shared page mapped.

I'd still love to know what actual kernel drivers and actual userspace would be involved in this whole dance.  It's still way too theoretical for me.