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 11074C77B7F for ; Tue, 16 May 2023 18:34:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B542900003; Tue, 16 May 2023 14:34:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96EF2900002; Tue, 16 May 2023 14:34:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DEC6900003; Tue, 16 May 2023 14:34:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6B6D4900002 for ; Tue, 16 May 2023 14:34:07 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 39B0FADB5F for ; Tue, 16 May 2023 18:34:07 +0000 (UTC) X-FDA: 80796967734.26.AAC0776 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf01.hostedemail.com (Postfix) with ESMTP id 8A12B40016 for ; Tue, 16 May 2023 18:34:04 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QO4pOnEa; spf=none (imf01.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.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=1684262045; 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=6afsqKcFjA8vJgHW3M1WvxLEpDEZ/LpdA4swifq6OkU=; b=zvl7x1p45e9JsA7X4MhFAzS/aes6iwj9iIFqKsKYztqtAb7vazl//bLGE9iZELI5l9hHZZ lu3MxbKE0ri8EIT/tKtomHb+B/KUQr3pXx+pmzFGLkuG7QoDxIkBPo5uuA+jgRyBUcdFn6 2/Ca3Eaw9I2oHdwkpUKbClKZiPdhEBE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684262045; a=rsa-sha256; cv=none; b=vMHmC4UYre5N4bsjIVOkQeKitzwI0TPxeXHvee7PBn0PAZzlG1Lk88MwCKCpEeJpKCtlLT gOzKFw/GZHH+6ob3zaU85xCV89+8z8CDR68YMwgbsB4kIvjikar1mrdS9e9ScRS7fJgN8w QW+B1qdKMoA2X2oNvtVNPDeLJx1xUKA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QO4pOnEa; spf=none (imf01.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684262044; x=1715798044; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WiNKNJZjFGE/z2NUf2w+RqrYzrUuUbxjZ+jb70aRrI8=; b=QO4pOnEaCl7UzLmLmdzj7acj10yi8yVN1dIhUz+X69TB1AlY2ciehZYo A+znCIxS4ADd+Oe1epk5P8I7S0sWxQzATK3CzkHqwLZb3+tcxb02X1tii sGDaw6Thnl0Jtj9g0ciowtA3z73HvXuUD6cuIQA2rNLw+1C0G/YjEGMEG FSs6ivuT05b8mULChdPx0Yn+yaVfDnvSV9V80wDPjoy0LREZEFlFtShrT YLFRabT//98n7Ayc6LtDEt0Euq9Mv9elWETcN1wir6J4neNRNG/ZQSyHH GgWhE4TwdSYoLHP1J1TLKMn5mkxD2JuXOU9/BYeTsRMmrj50QcqSBG9Fz g==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="379743583" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="379743583" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 11:34:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="695575469" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="695575469" Received: from unisar-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.219.243]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 11:33:55 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 4F38710C8C1; Tue, 16 May 2023 21:33:52 +0300 (+03) Date: Tue, 16 May 2023 21:33:52 +0300 From: "Kirill A. Shutemov" To: Ard Biesheuvel Cc: Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Hansen Subject: Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory Message-ID: <20230516183352.5fvmqca34cjcv462@box.shutemov.name> References: <20230513220418.19357-1-kirill.shutemov@linux.intel.com> <20230513220418.19357-7-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8A12B40016 X-Stat-Signature: 1ygpn7p8hpr9xeixmpesqkds5onmjsir X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684262044-60189 X-HE-Meta: U2FsdGVkX18hEQdfgvq77dpRMiyjXQrtLQrX4FLlwkc8qtF7sEJPlw4tZpX7YTR/DMahpUvi3hXEPepiCEku77EKHS60dgzOwOO5dND3XpglV2Au00C2tLyQUhm+Xomqj+HhHH+raIC51K3D+1bAUmHxztzJSa92VQfSA7CIgaycb5977/S0ABwehZ8kOnOga51RQHo6OTVVIByIYjcb4LNBfo2Nkxqbw5kRXIH1jNG0/QsJjXmdS48ULypm9y+lD369aYPEc07wEK7MB6RaYsJtAipSBgoPKIEJ0xcEEPq/mM77mflHJEByXkvWPuQn65iBHgy5dK1Te4PBHLK5KgP5b61yHFZk3WGk9e3lU8FED5QNN8y00/THmzMop/CDF0Vt1mRe5nt2jOFw2gCHERYlgXNoNMbcVZwGOtiawspeEAoBA7wAz+31ythxJUivBV3Wz/KT5IUdCPear3l6IKV8YGKnIkmI+ukfVHehTnoujo9ybo8fFS8twN61qOsdwZURpU/n/4iSVFciiJSOUh/4DQT6Wkwp/Efiod+/4jRMlsHlzO7B/3umjHFFpekSIp0eWar3aLZ85JsO3eCzJxC9Cc/ujnEYnYZkptWHUnQ13s7UbmD0jkkFI90ccYzlHma1CpLUfDxF2J6n/K3k7MTnJM+yLN5CfSg0VbDm4Bxvq68GrmGzEyizIHVusCDK/2/1PSonW9Rzi95Mv7ch3271xIXgpqTzd+2RwY/zkH1ejBbzdgkBpxfYGIdWs+9+WU03IXMY+O/0LRrQ3XC7MKza2uz+dx5zvfC5BGKQq5FYfss7e9Ewz7gbkJZVPIMn8p1ziOXkFFZfIJNgOyM7MWV+/OmdCLIjGnhUpH+hMdvZ433jDPdqUsrc3wPY8X0Jt93DARMSU+u4fYD7QgJxHh4ZoqVCqxIMq9wB9FiVgQ3KNszpZFRtecEQXFNXety9EAEYEQs7CdmFPWCKE2G Owk5UNb6 V8wFTd6g0halTU4oS2lp30WXoEZeDKQVdOsSo4dr5PX99snqtFKdri7KXALzq9c+EaBtFRUnMqsa4i9BDZ/cYx25xuGBdoErW5VYNqXwiwVdYcY68XPkeS9vhxXHSF78yky1fzfnDL5nPxUjwdiStDWe40viHJJq96SRRLPVTAjDyxrS63jDe1ec7Cw== 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 Tue, May 16, 2023 at 08:08:37PM +0200, Ard Biesheuvel wrote: > On Sun, 14 May 2023 at 00:04, Kirill A. Shutemov > wrote: > > > > load_unaligned_zeropad() can lead to unwanted loads across page boundaries. > > The unwanted loads are typically harmless. But, they might be made to > > totally unrelated or even unmapped memory. load_unaligned_zeropad() > > relies on exception fixup (#PF, #GP and now #VE) to recover from these > > unwanted loads. > > > > But, this approach does not work for unaccepted memory. For TDX, a load > > from unaccepted memory will not lead to a recoverable exception within > > the guest. The guest will exit to the VMM where the only recourse is to > > terminate the guest. > > > > Does this mean that the kernel maps memory before accepting it? As > otherwise, I would assume that such an access would page fault inside > the guest before triggering an exception related to the unaccepted > state. Yes, kernel maps all memory into direct mapping whether it is accepted or not [yet]. The problem is that access of unaccepted memory is not page fault on TDX. It causes unrecoverable exit to the host so it must not happen to legitimate accesses, including load_unaligned_zeropad() overshoot. For context: there's a way configure TDX environment to trigger #VE on such accesses and it is default. But Linux requires such #VEs to be disabled as it opens attack vector from the host to the guest: host can pull any private page from under kernel at any point and trigger such #VE. If it happens in just a right time in syscall gap or NMI entry code it can be exploitable. See also commits 9a22bf6debbf and 373e715e31bf. -- Kiryl Shutsemau / Kirill A. Shutemov