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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E507C433DB for ; Fri, 12 Feb 2021 13:19:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C878764E57 for ; Fri, 12 Feb 2021 13:19:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C878764E57 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 605C58D005D; Fri, 12 Feb 2021 08:19:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58EE88D0057; Fri, 12 Feb 2021 08:19:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47D8F8D005D; Fri, 12 Feb 2021 08:19:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2D0CC8D0057 for ; Fri, 12 Feb 2021 08:19:11 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD64F8249980 for ; Fri, 12 Feb 2021 13:19:10 +0000 (UTC) X-FDA: 77809671660.28.9ED669E Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf30.hostedemail.com (Postfix) with ESMTP id 31192E0011C5 for ; Fri, 12 Feb 2021 13:19:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 340A8B029; Fri, 12 Feb 2021 13:19:09 +0000 (UTC) Date: Fri, 12 Feb 2021 14:19:07 +0100 From: Joerg Roedel To: David Rientjes Cc: Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , "Kirill A. Shutemov" , Andi Kleen , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Christoph Hellwig , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Message-ID: <20210212131907.GI5453@suse.de> References: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 31192E0011C5 X-Stat-Signature: drht3aeu5spno3m8585gsu8hcsiffp1p Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1613135948-517072 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: Hi, On Mon, Feb 01, 2021 at 05:51:09PM -0800, David Rientjes wrote: > I think quite invasive changes are needed for the guest to support lazy > validation/acceptance to core areas that lots of people on the recipient > list have strong opinions about. Some things that come to mind: > > - Annotations for pages that must be pre-validated in the x86 boot > sequence, including IST stacks The problem is two-fold: 1. How to pass the information about pre-validated memory through the whole boot process. This includes firmware, boot-loader, Kernel decompressor and the early Linux boot code. 2. How to keep track of validated memory at systems runtime. (I omit the kexec case for now) For 1. the best option I see is passing this information as part of the Linux boot protocol: - First we should require from the firmware that everything in the memmap which is not marked as E820 Usable is already validated. This includes any memory used by the firmware itself. - Then we can pass this information up the boot process by extending struct boot_params. The bootloader can pass which E820 usable memory it validated, same for the kernel decompressor. The text+data (but not bss) of the running kernel image is per definition validated by the decompressor and does not need to be added explicitly to boot_params. - Once the running kernel image took over there are multiple choices. The simplest is probably to keep a validation log, but other data structures can work too until the memmap is set up. The benefit of passing it up via boot_params is that the whole process does not necessarily rely on EFI. There are some use-cases for SNP and TDX like lightweight container runtimes with only minimal or even no firmware. > - Proliferation of these annotations throughout any kernel code that can > access memory for #VC or #VE > > - Handling lazy validation of guest memory through the core mm layer, > most likely involving a bit in struct page flags to track their status Yes, I would also prefer tracking the validation info in 'struct page', once those are set up. We can discuss different options, there is no strict need for using struct page, it just seems natural to me. > - Any need for validating memory that is not backed by struct page that > needs to be special-cased When everything that is not E820 Usable is already validated then this should be a no-brainer. Shared memory with the HV and MMIO memory is not guest private anyway, so there should be no issues. Just a page_is_ram() check in the #VC/#VE handler is needed. Regards, Joerg