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 24D11C7EE23 for ; Tue, 16 May 2023 22:15:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80317900003; Tue, 16 May 2023 18:15:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B3A2900002; Tue, 16 May 2023 18:15:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67A71900003; Tue, 16 May 2023 18:15:51 -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 545EB900002 for ; Tue, 16 May 2023 18:15:51 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 102B14044A for ; Tue, 16 May 2023 22:15:51 +0000 (UTC) X-FDA: 80797526502.12.A8BA0C9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 9EF88100010 for ; Tue, 16 May 2023 22:15:47 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aWUPGge+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684275347; 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=Pb/qFhxBLgovJmQJ0/96J8qVL7adD4F5qjbc56++jyQ=; b=wDwNiuzEgutRGxBSgk3UTIznAPEhPFhZIU2SviXidr/5SfaKT85dGXx8hixbHonQKSHhkM 2dWSS97wy+Lm+GbpDvyrp/FZN+03kAfWqZMYIPOuX0i9cKD6A2MsUtSIwMgpR3ztEv/hmv XUS4t0sMjHJz6Smt0kr+o+0i/1c+V24= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aWUPGge+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684275347; a=rsa-sha256; cv=none; b=ri77JTsOlXh2GYd9QzBcJ/YCvbLyVACtU2EUaS9XlyKuo4+PSt8RqI2QeXTG4vypSVQLQj tPkP49CIrTYMbxAL0o/klnII+cLi19RwLC2jrTd2KXN3DuXm6qr2+k+uuXP9YUuTdM6ORm gAOzeVDXRAdLr0+f830qUowiqKD681Q= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9D66D63FF1 for ; Tue, 16 May 2023 22:15:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE82DC4339B for ; Tue, 16 May 2023 22:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684275346; bh=1CVkm2h1qch1auKHIlF0XC2larxx6NtF2jvkbfM3xkE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aWUPGge++7R+LkdH9wAMZ8QfMdeNLVvaXSJr9NilVQbTDzw6BTdEVddosKdcxdhD9 S30pqFh//o9HnYmGeRS9ul4qgo9sWXPWI0BgRxgGNvTOogO8kTm1XtwBV8vo809Uo0 Be6kbCb3xJDy7bYKC/HaU4GaXRWNONGIqbhYgpsfKFt/8EVmvnmDDPcBYer1DjgD4h OSpyFGgJRKnTikAweQWSCMbB1gMzFtY2erMlQIkncHqm4scPKlnt2pPbuw0vEQIKe9 k5Bj9hPfiSKqROtzU6JfUIVN3+3NoOBEV4F79bHt31tiU3mWQPvc21FBPD8ZmhO/GY BITcFKmbsEhEg== Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2ac8d9399d5so140570401fa.1 for ; Tue, 16 May 2023 15:15:45 -0700 (PDT) X-Gm-Message-State: AC+VfDxpRThNl7qvIRWJzsKa52ADkJTqg3yK0D0NiX0qSb+CNFZsWbUR 6bxLXQRV6I3vpEVvBvCDBeVkd9sJrX4Wf35LFkQ= X-Google-Smtp-Source: ACHHUZ5mI+okYrvd0yt5zMehG48RxTQOQz4+Gycufmk9DgSt/lmCXjtU/NESXXGYNMmBUE7Ys4ZVWKH2l+eyPbWHGw8= X-Received: by 2002:ac2:5285:0:b0:4f2:6857:1d98 with SMTP id q5-20020ac25285000000b004f268571d98mr5554640lfm.48.1684275343279; Tue, 16 May 2023 15:15:43 -0700 (PDT) MIME-Version: 1.0 References: <20230513220418.19357-1-kirill.shutemov@linux.intel.com> <20230513220418.19357-7-kirill.shutemov@linux.intel.com> <6fe42f66-819c-f2c8-176b-759c1c5a9cf5@intel.com> <20230516215210.pviqojbr5o4hd6bb@box.shutemov.name> In-Reply-To: From: Ard Biesheuvel Date: Wed, 17 May 2023 00:15:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory To: Dave Hansen Cc: "Kirill A. Shutemov" , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ac44badadktudkycbtszpog7ygmkawqd X-Rspam-User: X-Rspamd-Queue-Id: 9EF88100010 X-Rspamd-Server: rspam07 X-HE-Tag: 1684275347-188867 X-HE-Meta: U2FsdGVkX19q3KtctPjgqvwKNkPqXpoOFctPTpiMhB/Q1XEs+W/Dpurj6EUpoagOTLimNTiAk+FpAMMMEgLqsJgJgWwGdUbR/z0Is3EU3cK5ufsYod9x8ysHCaLvv5j24pUmp3j6t1uwCRPG9/0/MzqVS5l/J4A8DLZyUx7yk+GXna/WT/LRdY/z7tUFqHye6GBN1SRGu4KR95oWo1GOWplW3NGSOvZmv5B8qzOjivqrmTDy5tOY8MsvFLDBbNKb2bI48nUd6rsylZEPaJOaFn1DKdQpYzQvmiBa/CXV2gO1X7XrK4e5wXPPK2DzwSicBQTg1uXIBTFyQqfKm7uW8WA37gGgiHUJ+fWkxqTM/U9+hUCYGwUFuzp6lJlnTC1Tv+Ed5aEqzjhYPfPNfl4QNfza/oSKq45dLkXpziEeTiyAQgWVm74sYBmDBZ4pAVedB1/6ABI1LTd01IraujcZZ0E12ZZ5RIvEe6DRILSCTm7sXAZWrSW2CAW4ohU4obUPJ0sMf9n5OqMkGkj/XSKYDW9XdU7z4Xfrek/xsIikAfTEcxiKk9VeS2VQApgO7w8FpTpt+KFMHluwip1a1CJYUUYME3/lQ/sq2AAXMKVTbluofTBXCSJMPFk9o0bmi6WYuey4uHVERCVJz9SGnS6qh8DWYIQXWyAZXqyARmQoW/qtE1tbDOATG+aVaqRrvbHIISgkj11HvCu3MjV0rBrnveHZlASzaREiCSApmNzWuNVfzcUhAOUAxi3hbp/tCvWc0dWQKAbacW2bXTNniUiPt28+X/CrbCqgfaLmokpVJRybTqqh8WNFyHykA8m/1rVUaZETsNIczhqDAwZvdSb4FMMSi44Y7R6dkkhbih8XoVevW7aC+nrnjXMKouKC0hTnsbJl6KY++0x1Udb85j4jbUtYelKTVcunLar+1vp9QWkGnf2cdv6bmd38speAL99vKs+FIWnkuOQGvVkoALV CvqUW9Sf eK9sJviv+lO6io7xbnHB9ymzzHoaqvKMzF3w2+hSUmt/1dDCUf+KR1u9pWobabMAKPXjmbUTOuuadFYEZjYfvlQgA3Mx54p0o0wK6bjK9Lujx5aBKesHKegabdW5ijzLyq+EXuD0rRZIVBBOMCWpnnhaBjnPUzbf6CWVi8jVG5i3V8/eYDL8xRMxuWmgsAuMx1hEgDi8+NaAT3OWpPgd62wIqQmVaPOIEB90C6a8A9OzE6mSONxyi6suPTB9iz3nM3BdUsX0m1VNzZaX259EGaMJSJl8omYKlsoTXmUPW9F4c1qgN8vy1zfmkG+74iSUrwPdYQcRdWKmgY1GlJc+5tDyph8LN/Vl2FGePd6a7o+nJ+AvNcoNcdkShZmAkRsRdsmmQi58wNCconM6vOwDCVjoFn0t+Y/npJXi/xKXcEETYHMrxGUv2AuCb9nGHF9uOXk6p 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, 17 May 2023 at 00:00, Dave Hansen wrote: > > On 5/16/23 14:52, Kirill A. Shutemov wrote: > > On Tue, May 16, 2023 at 01:03:32PM -0700, Dave Hansen wrote: > >> On 5/16/23 11:35, Ard Biesheuvel wrote: > >>>>> Does this mean that the kernel maps memory before accepting it? As > >>>>> otherwise, I would assume that such an access would page fault insi= de > >>>>> the guest before triggering an exception related to the unaccepted > >>>>> state. > >>>> Yes, the kernel maps memory before accepting it (modulo things like > >>>> DEBUG_PAGEALLOC). > >>>> > >>> OK, and so the architecture stipulates that prefetching or other > >>> speculative accesses must never deliver exceptions to the host > >>> regarding such ranges? > >> I don't know of anywhere that this is explicitly written. It's probab= ly > >> implicit _somewhere_ in the reams of VMX/TDX and base SDM docs, but he= ck > >> if I know where it is. =F0=9F=98=84 > > It is not specific to TDX: on x86 (and all architectures with precise > > exceptions) exception handling is delayed until instruction retirement = and > > will not happen if speculation turned out to be wrong. And prefetching > > never generates exceptions. > > Not to be Debbie Downer too much here, but it's *totally* possible for > speculative execution to go read memory that causes you to machine > check. We've had such bugs in Linux. > > We just happen to be lucky in this case that the unaccepted memory > exceptions don't generate machine checks *AND* TDX hardware does not > machine check on speculative accesses that would _just_ violate TDX > security properties. > > You're right for normal, sane exceptions, though. Same thing on ARM, although I'd have to check their RME stuff in more detail to see how it behaves in this particular case. But Kyrill is right that it doesn't really matter for the logic in this patch - it just accepts some additional pages. The relevant difference between implementations will likely be whether unaccepted memory gets mapped beforehand in the first place, but we'll deal with that once we have to. As long as we only accept memory that appears in the bitmap as 'unaccepted', this kind of rounding seems safe and reasonable to me. Reviewed-by: Ard Biesheuvel