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 3D990C433EF for ; Sat, 9 Apr 2022 20:41:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A979F6B0071; Sat, 9 Apr 2022 16:41:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A46F46B0073; Sat, 9 Apr 2022 16:41:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E7C66B0074; Sat, 9 Apr 2022 16:41:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 7F3726B0071 for ; Sat, 9 Apr 2022 16:41:48 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 42217B44 for ; Sat, 9 Apr 2022 20:41:48 +0000 (UTC) X-FDA: 79338511896.02.7EF73D4 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf03.hostedemail.com (Postfix) with ESMTP id BA36A20002 for ; Sat, 9 Apr 2022 20:41:47 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id y32so20391955lfa.6 for ; Sat, 09 Apr 2022 13:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BMIBppXLbzT5rl5nFL/hepo4NioK75rx70EFlK3wfVg=; b=lepNhCrBGbo6Pi4UwZtZjxnNpNKam79xcZ2yE+nshnF/7pOQtNz9cBGiFOCq8+iZ/R KyZem4RegVD60Jb0ugfQemqeSmesE9JDsGMIZyvTi1j61gwQC5Jl54+oPpv1qEr5nHz1 7pbES4ljfdOKsj90GujVIm4sYuJ/wmXEmGBdLv63FYxObZn8XoAfiGZLMbYDwddbpfjF 6E5mheUXex+HyhhDtq6MxEkTneL7i36JnCpqYAYjJwFb6KqLn+nTxFwqRY+kirGxhOFv xiCU9rWeYkH1OyQKscsMhac7t+82pKYSu9J6azjMg27rshE87VvuFnpRR4V9VjazQvmo GNkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BMIBppXLbzT5rl5nFL/hepo4NioK75rx70EFlK3wfVg=; b=lmd8zySE+5SKTTd7VTkwpYZibhRg/COYfxL/wftAgSJyvA0UCyHIGk/dQ9lrO6JVt/ p7/hOeCmMMtEv+3/jM2KLyqrajDz962btVc1g/rxG+Hv4HfdpkxAC7aaKp/OcYF+gG3D wzMqzk9/vdQXG92FZjX0gF6jgvNS6fqOooS02oHO63DSPfpP3+ZlJ2JWrOH2IGado46B kzLS4XlOLA0ECrTrUwQZ//TkdepL3YHqccyhmS65tfzvh6sOw1prpZ+1e2r5qAPuHO/C 1MfRSeQMd+vXVUQxdnwgcWxSs18PPi4xaTmkrmOZmlx+SM0R/iSsdnum63oGU+Ma3P49 +5Xw== X-Gm-Message-State: AOAM530bNtH2aElBbqJBaR0VIu3PZyMF1+UkbIozDxG8zzwAZJHzGf2n DtRZ3CBAoc29k3p+zyIZEQWWvw== X-Google-Smtp-Source: ABdhPJyuPYXGvF6wigXiMfnDCnvVB1xi6mYWsajnzN2iZF06d9C3dwPBU4jPaliEjax/9NqHH4gBnQ== X-Received: by 2002:a05:6512:3f13:b0:464:f55f:7806 with SMTP id y19-20020a0565123f1300b00464f55f7806mr9339683lfa.598.1649536905956; Sat, 09 Apr 2022 13:41:45 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id s12-20020a19770c000000b0046b87800f71sm517340lfc.49.2022.04.09.13.41.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Apr 2022 13:41:45 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B09B71039DB; Sat, 9 Apr 2022 23:43:16 +0300 (+03) Date: Sat, 9 Apr 2022 23:43:16 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: "Kirill A. Shutemov" , Borislav Petkov , 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 , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: Re: [PATCHv4 5/8] x86/mm: Reserve unaccepted memory bitmap Message-ID: <20220409204316.bv5qmuqtstml6knx@box.shutemov.name> References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-6-kirill.shutemov@linux.intel.com> <1ac804b3-eaaf-e87d-2fb5-30125c81ae28@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ac804b3-eaaf-e87d-2fb5-30125c81ae28@intel.com> X-Stat-Signature: cdwsc9xxgyduw73jbp7skmj5trey8ezx Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=lepNhCrB; dmarc=none; spf=none (imf03.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.46) smtp.mailfrom=kirill@shutemov.name X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BA36A20002 X-HE-Tag: 1649536907-74024 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 Fri, Apr 08, 2022 at 11:08:48AM -0700, Dave Hansen wrote: > On 4/5/22 16:43, Kirill A. Shutemov wrote: > > A given page of memory can only be accepted once. The kernel has a need > > to accept memory both in the early decompression stage and during normal > > runtime. > > > > A bitmap used to communicate the acceptance state of each page between the > > decompression stage and normal runtime. This eliminates the possibility of > > attempting to double-accept a page. > > ... which is fatal, right? Could you include that an also the rationale > for why it is fatal? Actually, no. For TDX, TDX_ACCEPT_PAGE would just return an error. It is not fatal, but it indicates that there is security hole. VMM can clear the range of the memory if it can trick the guest to re-accept the memory blindly: 1. VMM removes the memory range from the guest. VMM can do it at any point. 2. VMM re-adds memory for the same range of the guest physical addresses. 3. VMM tricks guest into re-accepting this memory blindly. It makes the range of guest physical memory filled with 0. 4. ??? 5. PROFIT! TDX relies on guest to be careful with accepting memory and only do this for memory that is not in use. This patchet is designed to keep unaccepted memory accounted and prevent such double accpept. > > The bitmap is allocated in EFI stub, decompression stage updates the state > > of pages used for the kernel and initrd and hands the bitmap over to the > > main kernel image via boot_params. > > This is really good info. Could we maybe expand it a bit? > > There are several steps in the bitmap's lifecycle: > 1. Bitmap is allocated in the EFI stub Allocated and populated. > 2. The kernel decompression code locates it, accepts some pages before > decompression and marks them in the bitmap. > 3. Decompression code points to the bitmap via a boot_param Actually EFI stub makes boot_param point to the bitmap. Decompression code and main kernel consume it from there. > 4. Main kernel locates bitmap via the boot_param and uses it to guide > runtime acceptance decisions. > > > In the runtime kernel, reserve the bitmap's memory to ensure nothing > > overwrites it. > > > > Signed-off-by: Kirill A. Shutemov > > Acked-by: Mike Rapoport > > --- > > arch/x86/kernel/e820.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > > index f267205f2d5a..22d1fe48dcba 100644 > > --- a/arch/x86/kernel/e820.c > > +++ b/arch/x86/kernel/e820.c > > @@ -1316,6 +1316,16 @@ void __init e820__memblock_setup(void) > > int i; > > u64 end; > > > > + /* Mark unaccepted memory bitmap reserved */ > > + if (boot_params.unaccepted_memory) { > > + unsigned long size; > > + > > + /* One bit per 2MB */ > > + size = DIV_ROUND_UP(e820__end_of_ram_pfn() * PAGE_SIZE, > > + PMD_SIZE * BITS_PER_BYTE); > > + memblock_reserve(boot_params.unaccepted_memory, size); > > + } > > One oddity here: The size is implied by the e820's contents. Did you > mention somewhere that unaccepted memory is considered E820_TYPE_RAM? > It *has* to be in order for e820__end_of_ram_pfn() to work, right? "e820_type = E820_TYPE_RAM;" for "case EFI_UNACCEPTED_MEMORY:" in patch 3/8 does this. I didn't wrote down it explitictly. I will. -- Kirill A. Shutemov