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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BAA7C433EF for ; Mon, 20 Dec 2021 18:10:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240313AbhLTSKl (ORCPT ); Mon, 20 Dec 2021 13:10:41 -0500 Received: from mail.skyhub.de ([5.9.137.197]:48512 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230489AbhLTSKj (ORCPT ); Mon, 20 Dec 2021 13:10:39 -0500 Received: from zn.tnic (dslb-088-067-202-008.088.067.pools.vodafone-ip.de [88.67.202.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E2F431EC02AD; Mon, 20 Dec 2021 19:10:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1640023829; h=from:from: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; bh=u3qadLJLiGlSgg2xgOL2YC+8FxEP43TobdqfUt7kZfs=; b=QmswxF0+lNGM5M1aASyqrDia50ovg/fASW425kO6II3UgRUEDk7qDKW5x2diW9uBn4cFwN 8Go6v7DlrLikQSAnRE9A53xfP+VfrhPTF04qONhX2QpcnXQbJq28hRJ2+dpkX1JUdu1SCs pp11efyKP/pk75Bs0dtNIKKVTQuMxVY= Date: Mon, 20 Dec 2021 19:10:31 +0100 From: Borislav Petkov To: Tom Lendacky Cc: Brijesh Singh , Mikolaj Lisik , Venu Busireddy , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v8 08/40] x86/sev: Check the vmpl level Message-ID: References: <20211210154332.11526-1-brijesh.singh@amd.com> <20211210154332.11526-9-brijesh.singh@amd.com> <79c91197-a7d8-4b93-b6c3-edb7b2da4807@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 17, 2021 at 04:33:02PM -0600, Tom Lendacky wrote: > > > > > + * There is no straightforward way to query the current VMPL level. The > > > > > + * simplest method is to use the RMPADJUST instruction to change a page > > > > > + * permission to a VMPL level-1, and if the guest kernel is launched at > > > > > + * a level <= 1, then RMPADJUST instruction will return an error. > > > > Perhaps a nit. When you say "level <= 1", do you mean a level lower than or > > > > equal to 1 semantically, or numerically? > > > > Its numerically, please see the AMD APM vol 3. > > Actually it is not numerically... if it was numerically, then 0 <= 1 would > return an error, but VMPL0 is the highest permission level. Just write in that comment exactly what this function does: "RMPADJUST modifies RMP permissions of a lesser-privileged (numerically higher) privilege level. Here, clear the VMPL1 permission mask of the GHCB page. If the guest is not running at VMPL0, this will fail. If the guest is running at VMP0, it will succeed. Even if that operation modifies permission bits, it is still ok to do currently because Linux SNP guests are supported only on VMPL0 so VMPL1 or higher permission masks changing is a don't-care." and then everything is clear wrt numbering, privilege, etc. Ok? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette