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 D7B7EC46CD2 for ; Tue, 9 Jan 2024 12:45:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 653C36B0082; Tue, 9 Jan 2024 07:45:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DD6A6B0083; Tue, 9 Jan 2024 07:45:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4572B6B0085; Tue, 9 Jan 2024 07:45:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 336A36B0082 for ; Tue, 9 Jan 2024 07:45:30 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0667BA0893 for ; Tue, 9 Jan 2024 12:45:30 +0000 (UTC) X-FDA: 81659743620.22.065FE41 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf25.hostedemail.com (Postfix) with ESMTP id 0318CA0018 for ; Tue, 9 Jan 2024 12:45:27 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=P3vWCRHo; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704804328; 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=l6b0BVWYus0PqvwNEk2f7GpDUFZb2PXSAO/GejNElUA=; b=yp3o3ICnVBJcjFkYmUqjJ7AgIUlQIvPLAIVsGtw6iVx+aUqG0cHO58n7nsGVRVMQbRrVcZ TfxY007Dysh0+8E8PIxosDSMQmaVC+ZEsAP8wq3HZxgFJa9WawJEqvEu82VsXKGn/X+j5z pikZVz2PeZ4qMFkHbddQfjPfCiZ4ed4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=P3vWCRHo; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704804328; a=rsa-sha256; cv=none; b=RA4wr9hHa9thcHWMr46fdAoa7ZVBGbJSxLBFjQGx5aVIzMYVGsVcGdV4XrXEMCvJvxklet Aan7OXNGb+D4e8tx7qS77G91CvwtUhHEADwRiJR0vV9XOniNEbLAoouizmDxjwrbjjLj1O 0U/YolIDoZz0HgID3nzPFvYHifnLdhw= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id C5EDB40E01B2; Tue, 9 Jan 2024 12:45:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8JN_jPoAT9UY; Tue, 9 Jan 2024 12:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1704804322; bh=l6b0BVWYus0PqvwNEk2f7GpDUFZb2PXSAO/GejNElUA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P3vWCRHonjL26YO014HkDzmHfhlyWvUpkuqIEPLXmV5eJ6Q4HswyJIiLdCq75I/tc Y7Lqd6l5lCkjB1JZRE4EF7T8eyRhELDXngGcqWwMI/3mQZpI50KOA0Gmjvo+69HuS8 n6TZ95AZFoyCuQW9z8vz8SPac5eetbfupizS08/01RM4MPNyNkXsge5GtptNLRHrq4 8aS72rGot0EIdY8gRNmoujNrFPgrg8SKJs/SKuT/Vpo6n6qAOtL0ccrAvx6y8xMDvG dmqSGzlx7F6yOD3YqtjplBih06OELzh1ouH6b32/zyPV4ZV/rDq5hm3y/ili1YRrfm LB3ULJANtMn33Ocx3ZP8oyp0ONqAgvUjXcw/E4hX6UnZr9hTrrO9iff5N89D3ltHLR JCEXwEDP1mRsoi9kCKG5DK1CswarhfyY5jdBTZQejQgd5eisdRaOQLYPEu6O/ouEaf zZ3esY5AxUJZQeR35pBzbCUj31lahwt+PHpqJp9eVgjywOTA2ngPbKuPdgaFwqwKIb 68ngs77We4wQiFOCjSQr/w2Se3FUxh9rxbfMAV01fYUUqS3JXb4WQEtScEkZtx2dF0 H6nyFxBskt06YADAQ2otuQ68m+yCRo4zpo/KnTsFgjhSyy/p3wTaDebIwcr7o3Kr7/ yxAy0oTE3aG+3thy44+MQJSM= Received: from zn.tnic (pd9530f8c.dip0.t-ipconnect.de [217.83.15.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 05E5540E01B0; Tue, 9 Jan 2024 12:44:44 +0000 (UTC) Date: Tue, 9 Jan 2024 13:44:40 +0100 From: Borislav Petkov To: Jeremi Piotrowski Cc: Michael Roth , x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, "liam.merwick@oracle.com Brijesh Singh" Subject: Re: [PATCH v1 04/26] x86/sev: Add the host SEV-SNP initialization support Message-ID: <20240109124440.GDZZ0/uDY9RRPIOxOB@fat_crate.local> References: <20231230161954.569267-1-michael.roth@amd.com> <20231230161954.569267-5-michael.roth@amd.com> <20240105160916.GDZZgprE8T6xbbHJ9E@fat_crate.local> <20240105162142.GEZZgslgQCQYI7twat@fat_crate.local> <0c4aac73-10d8-4e47-b6a8-f0c180ba1900@linux.microsoft.com> <20240108170418.GDZZwrEiIaGuMpV0B0@fat_crate.local> <20240109122906.GCZZ08Esh86vhGwVx1@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240109122906.GCZZ08Esh86vhGwVx1@fat_crate.local> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0318CA0018 X-Stat-Signature: 3c1ry7w7s71mtup1ptwur18okhf8t9yh X-Rspam-User: X-HE-Tag: 1704804327-688080 X-HE-Meta: U2FsdGVkX1+3viqCoLj6IiYCd7z28QlEKmFeD+P2NcgD53jOJjJ1/nYjvTx1wD10daLHM6ku5ly2AUMZL6HzVWUIZdOwmTdExOe1rabaML+k5AF/7DIdDi9goYzhQaXx/MKFvRKXkT4j9hQgsDTZqFJQ8im73EqO1jMDtzwMP7IjsBLbihZeaqdzVdf/a6pNv+iKDNYI6FdxINgBPpSeoRZYW/+rJVN7mG29UXjKk0S/IgKlQwKtYiVkju/+zbJB6gaCfDEhpVFEndTxusvvmko4z/DotHGSE+Gb2tlDkrjhtU/5d5e+VheLEeWDlO8GVIBzl2KYJS6tEEqLbCMYnerwPGjzkzplBPydAi+CGa2JXFQvA5+filWgK3nqiaDLbvqloWTCGU2wsTa4eTXKlprYa7GpKqVyX6xcO//uLFYQzBygRmZEAII36gEVQ+3sTTyEu1UL6YOE/vQe7ypvV2h3aBqnzzO0Et0ohnwBlkfHCPEP+NX93BNJDML7dkUOwUogDhuSZiMFfu6OX1yUdv15cdPuaPnp+ocANELQhxBfEp+hk7O0ZsNXNxz7qzQADt/o0asO0Cf014s/YRtUiFbP3PCqi81sxaXVW3gczkbZitAvBxOmgMHM0ogPuXUHja0ncnbKY0i5yeWWJI54oE5X3I/PVxHDOA6NXPI+tT05bdljghKEjKnuEYFa3ScFG6ciMiOd4AILs3OfuDdRiTHSxzvRjQt53/r5gK+eF/PBU//Z2VPPfATNpdEByeN4DrjnOhrPm4Z2+dapclJtTst6ZGidQY+e6V1LVAgUyaD42oBg5fUmWWR5Vg/jm5mCsvBsz6YY3/WqRdtteqK3OpBxOeMa3MyVv26nnHE3bv2l+g9eiVHn0Rzc8ZyT4WkFLITwIsG/gzw/7rQgUwV29fcYnMZpZ+AhP9pCaWWzSqr9BBs3MfpHmGaT+PVxR08YtxSY77JB6cV8o5E8WGk PCd1Sb5/ NUxFgV90gGCBjcmW9mdoDclF/FJNTvib3lGQEaiPf+5BXiqzJmEdL+aGOG/2trq1+0jK5fwEVYmi28IFkwjJpqogmjKjOLyNm3ycZTy6S0G4+R4xAl0McyzTC0khDKoIPQaZX/u4s1pT8ecI4ztxvfI5Q2v3xbEY1Yml26706qyOeHrVGiY7USz8U2NxKopiqIv99ELiDeozZNtpaKfyXasUgkezddoM5r9qU 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: List-Subscribe: List-Unsubscribe: On Tue, Jan 09, 2024 at 01:29:06PM +0100, Borislav Petkov wrote: > At least three issues I see with that: > > - the allocation can fail so it is a lot more convenient when the > firmware prepares it > > - the RMP_BASE and RMP_END writes need to be verified they actially did > set up the RMP range because if they haven't, you might as well > throw SNP security out of the window. In general, letting the kernel > do the RMP allocation needs to be verified very very thoroughly. > > - a future feature might make this more complicated - What do you do if you boot on a system which has the RMP already allocated in the BIOS? - How do you detect that it is the L1 kernel that must allocate the RMP? - Why can't you use the BIOS allocated RMP in your scenario too instead of the L1 kernel allocating it? - ... I might think of more. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette