From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D65ABC19F2A for ; Thu, 11 Aug 2022 11:27:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 676728E0001; Thu, 11 Aug 2022 07:27:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 626336B0074; Thu, 11 Aug 2022 07:27:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4ED478E0001; Thu, 11 Aug 2022 07:27:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4152F6B0073 for ; Thu, 11 Aug 2022 07:27:07 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0C983ABF04 for ; Thu, 11 Aug 2022 11:27:07 +0000 (UTC) X-FDA: 79787085294.12.5736891 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf19.hostedemail.com (Postfix) with ESMTP id 03E131A015F for ; Thu, 11 Aug 2022 11:27:00 +0000 (UTC) Received: from zn.tnic (p200300ea971b9854329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971b:9854:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 247F21EC056D; Thu, 11 Aug 2022 13:26:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1660217204; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=UY0huCcMksTkB4oLQLF5MAgiiZEs9HuLdo2XFb9uvQw=; b=rmFZk2nFgA8PrMSlwDnyIhuf8Azrn/VmdGgQEjg3g7nzV/uXykxOaiNeOXhEuPPb5Y8Xna OomDtJMKKThisqRUyqWX9k0TBb4IO3OpJ68MEGE5BLGOuTXKJt46Pm+o7a6J8CqM8/Q/A5 rNB4EJb0S/cMZ6BULpUInSoHeE/W8AI= Date: Thu, 11 Aug 2022 13:26:40 +0200 From: Borislav Petkov To: Dave Hansen Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory Message-ID: References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-11-kirill.shutemov@linux.intel.com> <80cc204b-a24f-684f-ec66-1361b69cae39@intel.com> <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660217225; a=rsa-sha256; cv=none; b=MnmRCZQydiiuKuxGTBgh3s5SlrYeVCXOpgfJoapApLz0rFiNWQiFxJANQBa83EnVteeJpl v6YjL/3GWTogLa0SchoO3I+RAm9Tm2jx274unRrH2BfaJteV8I2MT9V4J+kif1c94jzbGj h+WhIAAXHbfu1/deZ8avdrO/e1u7BS8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=rmFZk2nF; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror); spf=temperror (imf19.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660217225; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UY0huCcMksTkB4oLQLF5MAgiiZEs9HuLdo2XFb9uvQw=; b=dQnKoi/XQI144hlbgqWCyNT/GgR215vLSg1xz1HWDOLiS0SsqKj4bcGcFqYBjTrIF1fYj0 HSOkYKZ0+Mq+TXXSBowNi1Pic+F/dLYgyr86wdaMxhuH3HXIyi63KPQcXej5RUcIh5KmNq EeDlZhEE0ERy8HN1Fwc4j2jgFzEZ4l0= X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 03E131A015F Authentication-Results: imf19.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=rmFZk2nF; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror); spf=temperror (imf19.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de X-Rspam-User: X-Stat-Signature: jty9dujau335a8wt89fedqsni1jab3ts X-HE-Tag: 1660217220-100561 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 03, 2022 at 07:02:31AM -0700, Dave Hansen wrote: > One other thing I remembered as I re-read my write up on this. > > In the "new" mode, guests never get #VE's for unaccepted memory. They > just exit to the host and can never be reentered. They must be killed. Yeah, this is the part which I think is really silly. OSes, in their execution lifetime, can - erroneously or not - but it happens pretty often in real life, touch some unrelated memory. And this has never been a big deal - #PF, that's it. But now they don't even get a chance to correct their mistake - VMEXIT, die. load_unaligned_zeropad() is just one case. Imagine the user loads some buggy driver in the guest and that driver starts doing stray memory accesses through a wild pointer into the fields. Guest dies immediately. Dunno bit it all feels a bit too harsh and unfriendly to me. Sure, if that user is really unlucky, those stray accesses can kill his OS on baremetal too. So maybe you could argue here that such stray accesses are actually a good thing. :) All I know is, there should be a more resilient way to handle those. > In the "old" mode, I _believe_ that the guest always gets a #VE for > non-EPT-present memory. The #VE is basically the same no matter if the > page is unaccepted or if the host goes out and makes a > previously-accepted page non-present. > > One really nasty implication of this "old" mode is that the host can > remove *accepted* pages that are used in the syscall gap. That means > that the #VE handler would need to be of the paranoid variety which > opens up all kinds of other fun. Yeah, I believe this needs to be dealt with anyway, for SNP at least. But on AMD it would simply cause an exception and it'll be handled in the #VC thing. And there's some ugly code to deal with the gap too. > * "Old" - #VE's can happen in the syscall gap > * "New" - #VE's happen at better-defined times. Unexpected ones are > fatal. > > There's a third option which I proposed but doesn't yet exist. The TDX > module _could_ separate the behavior of unaccepted memory #VE's and > host-induced #VEs. This way, we could use load_unaligned_zeropad() with > impunity and handle it in the #VE handler. At the same time, the host > would not be allowed to remove accepted memory and cause problems in the > syscall gap. Kinda the best of both worlds. I like that. This should've been the default from the get-go. Oh well, what's it called in English, hindsight is 20 20...? > But, I'm not sure how valuable that would be now that we have the > (admittedly squirrelly) code to avoid load_unaligned_zeropad() #VE's. I think you should push for the bestest solution and one day we can kill those ugly workarounds. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette