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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 5A41BC07E9B for ; Wed, 21 Jul 2021 00:35:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D446460BBB for ; Wed, 21 Jul 2021 00:35:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D446460BBB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6D1366B0011; Tue, 20 Jul 2021 20:35:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6815F6B0036; Tue, 20 Jul 2021 20:35:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 521A06B006C; Tue, 20 Jul 2021 20:35:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id 316A26B0011 for ; Tue, 20 Jul 2021 20:35:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A9BE91848CB93 for ; Wed, 21 Jul 2021 00:35:31 +0000 (UTC) X-FDA: 78384726462.21.A30B137 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf08.hostedemail.com (Postfix) with ESMTP id 99C663000DA4 for ; Wed, 21 Jul 2021 00:35:30 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="211348865" X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="211348865" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 17:35:28 -0700 X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="501088279" Received: from tassilo.jf.intel.com ([10.54.74.11]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 17:35:27 -0700 Date: Tue, 20 Jul 2021 17:35:25 -0700 From: Andi Kleen To: Erdem Aktas Cc: Andy Lutomirski , Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , "Peter Zijlstra (Intel)" , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , the arch/x86 maintainers , linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <20210721003525.GC535804@tassilo.jf.intel.com> References: <20210720220113.GA535804@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 99C663000DA4 X-Stat-Signature: bei113hmbdfemg7caun7ofwyxsfkbyqw Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf08.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ak@linux.intel.com X-HE-Tag: 1626827730-900410 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, Jul 20, 2021 at 04:55:22PM -0700, Erdem Aktas wrote: > Thank you so much for your answer and sorry for keeping the discussion long. > > On Tue, Jul 20, 2021 at 3:01 PM Andi Kleen wrote: > > You mean when the TDVF is changed? In this case the unaccepted memory > > will be a different memory type, so not lazy accept enabled kernels wouldn't > > use it. > > Thanks Andi for the clarification. I also saw the Kirill's answer. It > makes sense. > > > But for the kexec crash case it would be just attacks against the crash > > dump, which I assume are not a real security concern. > > If the crash kernel is compromised, it can be used to dump the > customer memory content to a shared location which is a real security > concern, is it not? This wouldn't be about compromising the crash kernel, but just about inserting random zeroed pages into the crash dump. I assume the crash parsing tools can handle corrupted data, it certainly happens often enough with real dumps. The crash kernel itself would need to be properly pre validated/accepted of course, but that will likely happen when it loads. And the memory it uses could be re-accepted as long as it only happens before it is actually used (at least on Intel, there might be still the issue Joern pointed out on AMD, but I guess there it could be avoided by just pre accepting everything and setting up a suitable memory map) BTW with our current plan of disabling the #VE i don't think it can happen anyways. > > The crash kexec > > mostly runs in its own memory, which doesn't need this, or is small > > enough that it can be fully pre-accepted. And for the previous memory > > view probably these issues are acceptable. > > I think this is where I am getting confused. I agree that we can copy > the crashkernel to its own memory (all accepted) and run it. My > confusion is: crash kernel will dump the memory which might have some > shared pages between. we have 3 options: > 1- We can either accept all the pages again, that includes the shared > pages and lose the content of it. If we do not care about the content > in shared pages, then this is okay. On TDX this would lead to clearing the pages, which is definitely not what you want for a crash dump. > 2- Have a mechanism to transfer the private/shared page mapping and > map all the pages accordingly before dumping. FWIW we have very little shared mappings, and I suspect their content is probably not super important for debugging (no kernel data structures there). So even if you lost shared mappings for crash dumps it likely wouldn't be a problem. But actually it should just work. -Andi