From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E5812F23 for ; Sun, 6 Feb 2022 20:05:23 +0000 (UTC) Received: from zn.tnic (dslb-088-067-221-104.088.067.pools.vodafone-ip.de [88.67.221.104]) (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 491F71EC02DD; Sun, 6 Feb 2022 21:05:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1644177917; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+21t1u1IZ/DXSmDNGuY7CZg1bJNoX7TMMApbDOaYGnM=; b=EsQ5n6lUIseFFg6Ip/WrZGc3l5i1ZKojKis0VQ4XJ8xqdCSrk704FLOgENIOo43Dg9qZYn wVH6sXxY5zO4+fKByBmh2vQyWCqLBmr67x52yRmIOc8bd8ar/gE9ZQjbZdeET+fDUx1Qp2 e/KrT8L83lMhpzrB3AGPjpmXYrBSFcA= Date: Sun, 6 Feb 2022 21:05:11 +0100 From: Borislav Petkov To: Brijesh Singh Cc: 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 , Tom Lendacky , "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" , brijesh.ksingh@gmail.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v9 40/43] x86/sev: Register SEV-SNP guest request platform device Message-ID: References: <20220128171804.569796-1-brijesh.singh@amd.com> <20220128171804.569796-41-brijesh.singh@amd.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220128171804.569796-41-brijesh.singh@amd.com> On Fri, Jan 28, 2022 at 11:18:01AM -0600, Brijesh Singh wrote: > Version 2 of GHCB specification provides Non Automatic Exit (NAE) that can ^ ^ ^ the a event type > be used by the SEV-SNP guest to communicate with the PSP without risk from > a malicious hypervisor who wishes to read, alter, drop or replay the > messages sent. > > SNP_LAUNCH_UPDATE can insert two special pages into the guest’s memory: > the secrets page and the CPUID page. The PSP firmware populate the contents "populates" > of the secrets page. The secrets page contains encryption keys used by the > guest to interact with the firmware. Because the secrets page is encrypted > with the guest’s memory encryption key, the hypervisor cannot read the > keys. See SEV-SNP firmware spec for further details on the secrets page > format. > > Create a platform device that the SEV-SNP guest driver can bind to get the > platform resources such as encryption key and message id to use to > communicate with the PSP. The SEV-SNP guest driver provides a userspace > interface to get the attestation report, key derivation, extended > attestation report etc. ... > +static int __init init_snp_platform_device(void) snp_init_platform_device() > +{ > + struct snp_guest_platform_data data; > + u64 gpa; > + > + if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) > + return -ENODEV; > + > + gpa = get_secrets_page(); > + if (!gpa) > + return -ENODEV; > + > + data.secrets_gpa = gpa; > + if (platform_device_add_data(&guest_req_device, &data, sizeof(data))) > + goto e_fail; > + > + if (platform_device_register(&guest_req_device)) > + goto e_fail; > + > + pr_info("SNP guest platform device initialized.\n"); > + return 0; > + > +e_fail: > + pr_err("Failed to initialize SNP guest device\n"); > + return -ENODEV; So when someone tries to debug why the platform device doesn't register properly, this error message is ambiguous and two of the error paths don't even issue one. Either issue a different error message before you return each time or remove it completely and let someone who really needs it, add it. I'd vote for former... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette