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 7BEA5C19F28 for ; Wed, 3 Aug 2022 14:02:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 031E16B0071; Wed, 3 Aug 2022 10:02:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F23826B0072; Wed, 3 Aug 2022 10:02:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEAFF6B0073; Wed, 3 Aug 2022 10:02:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D039C6B0071 for ; Wed, 3 Aug 2022 10:02:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9AC29A1601 for ; Wed, 3 Aug 2022 14:02:42 +0000 (UTC) X-FDA: 79758446964.22.22E78B2 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf21.hostedemail.com (Postfix) with ESMTP id A435B1C013A for ; Wed, 3 Aug 2022 14:02:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659535361; x=1691071361; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=3kbiD6sIxSxAjVpFKmkjnzMfUr0hXQ3N3rtFHjcQbH4=; b=HujS2zSc2gj2GMAD6H9UKvC4z2wDAQ3lOWCWCdfgSZUrJmNUoB7qPY3B DVGYoA2uc59n0zj4sWJBADtNv+8jmM6Jtr/RVlLIiOzaGv1hlEU+KawZa HsbfYnIIhLIvYH9E0UeenOpfJWoyZtXtwneexpmdUXDLT5fVc1rf30whO 5Ir+KmqMXBPvHe6IB4SYA7bzDteNKEGug/qvI8pHb4yChlEYK3mGunK0Q OaQ29LUhECO/uVOCHXFiVnNcYqaHlMKb9XnuzcJL9ubsyFiUu1lxZk/uz 8HI+AmXhhY7SxrCn91oSc349V6e+e8kE2++J4bu8H2Kn9aZXPUNzDTbLQ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10428"; a="288433991" X-IronPort-AV: E=Sophos;i="5.93,214,1654585200"; d="scan'208";a="288433991" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2022 07:02:31 -0700 X-IronPort-AV: E=Sophos;i="5.93,214,1654585200"; d="scan'208";a="631159385" Received: from buichris-mobl.amr.corp.intel.com (HELO [10.209.124.150]) ([10.209.124.150]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2022 07:02:30 -0700 Message-ID: <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> Date: Wed, 3 Aug 2022 07:02:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory Content-Language: en-US From: Dave Hansen To: Borislav Petkov , "Kirill A. Shutemov" Cc: 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 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-11-kirill.shutemov@linux.intel.com> <80cc204b-a24f-684f-ec66-1361b69cae39@intel.com> In-Reply-To: <80cc204b-a24f-684f-ec66-1361b69cae39@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659535361; a=rsa-sha256; cv=none; b=kl9l89QYyMhKuIVHKS/QkDlsxp0goZoZ+MhgsZ9FheC9lIXbfYf9BOkmu9JpTyR4+fthJP FrXvJPaVqF5VdzZ5QA7q3dODF47SwDNiNK/FyuK0ZoAcSE62yMp7jAKrU08Nl7TmW1SU8G lyCpzVBmpaKPENIHrgYM/Xwd1mGtU4c= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=HujS2zSc; spf=pass (imf21.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659535361; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WVtdDF+Fy+grSt7TGYAvHZ6Xmo7A80+3mYKj8PtNfJM=; b=pKrDPzpau0qVxiVbvf0OYDtpGHRWq9MGsN2VHvDcRZxHmwCHESGqVXUrLlW0Q/iPgsn671 8og8fh2Mb2pKYaiztLX6iS233ZnSTgSOyyeENq/xIjKK3pgHHU62+fluwRwoxoaLuGdeSj 1TQLWM+B7gXPXzICdokdELoA4pJL7fU= X-Stat-Signature: m5zoyfocmqhwhkey4pego49b77e7ront X-Rspamd-Queue-Id: A435B1C013A Authentication-Results: imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=HujS2zSc; spf=pass (imf21.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1659535361-441785 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 8/2/22 16:46, Dave Hansen wrote: > To sum it all up, I'm not happy with the complexity of the page > acceptance code either but I'm not sure that it's bad tradeoff compared > to greater #VE complexity or fragility. > > Does anyone think we should go back and really reconsider this? 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. 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. * "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. 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.