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 8B041C433EF for ; Thu, 3 Mar 2022 17:33:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 206248D0002; Thu, 3 Mar 2022 12:33:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18F238D0001; Thu, 3 Mar 2022 12:33:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02F248D0002; Thu, 3 Mar 2022 12:33:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id E1BE68D0001 for ; Thu, 3 Mar 2022 12:33:50 -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 A212F8249980 for ; Thu, 3 Mar 2022 17:33:50 +0000 (UTC) X-FDA: 79203772620.28.D6298C0 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf26.hostedemail.com (Postfix) with ESMTP id AAA68140009 for ; Thu, 3 Mar 2022 17:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646328829; x=1677864829; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=/6BWrWtvMDgxG3GRtmu6+t9kH9b6E5eZZRPbC6t9AzU=; b=HhiXCt37uRg02kSCXe+sNwUwpRR1CCBCXGOHO1SzUxszNCslhEQraZPK SszUuXpqzhsJZVkLl7j6xM6Ft65Jt7MjGw/y11jkdTvU4O2vEmOlAOMFK a0mGa0RUFuuZ6O9gE5ce0B5b/nUZ5eFW7ikDIksArWE6Dh+T0S9DjUrmP NBNBmVM7lEJ2VnP+144jyA8tLxLJUBruChfraWJhNCJAu2oQDgi7peq5w 8mpBUX9Rw5OyWEsJu8dCqN1/Tt4dYTCs/gOQ5Wyq5MREYhzZGFCOWEmQH dKXJ4PnXexbgP0SNlse2BcagcV5F6xLI3ihrq2a0vcYA1M8fwCEaHg6Fo A==; X-IronPort-AV: E=McAfee;i="6200,9189,10275"; a="251320644" X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="251320644" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 09:33:48 -0800 X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="642197252" Received: from eabada-mobl2.amr.corp.intel.com (HELO [10.209.6.252]) ([10.209.6.252]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 09:33:45 -0800 Message-ID: Date: Thu, 3 Mar 2022 09:33:40 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Brijesh Singh , 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 Cc: 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 , Borislav Petkov , 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 References: <20220224165625.2175020-1-brijesh.singh@amd.com> <20220224165625.2175020-43-brijesh.singh@amd.com> From: Dave Hansen Subject: Re: [PATCH v11 42/45] virt: Add SEV-SNP guest driver In-Reply-To: <20220224165625.2175020-43-brijesh.singh@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AAA68140009 X-Stat-Signature: 9hywoi3r8wcfbsxjcrwyux7c1e8wg5hx Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HhiXCt37; spf=none (imf26.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646328829-626580 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: > +++ b/drivers/virt/coco/sevguest/Kconfig > @@ -0,0 +1,12 @@ > +config SEV_GUEST > + tristate "AMD SEV Guest driver" > + default m > + depends on AMD_MEM_ENCRYPT && CRYPTO_AEAD2 > + help > + SEV-SNP firmware provides the guest a mechanism to communicate with > + the PSP without risk from a malicious hypervisor who wishes to read, > + alter, drop or replay the messages sent. The driver provides > + userspace interface to communicate with the PSP to request the > + attestation report and more. > + > + If you choose 'M' here, this module will be called sevguest. ... > +/* Return a non-zero on success */ > +static u64 snp_get_msg_seqno(struct snp_guest_dev *snp_dev) > +{ > + u64 count = __snp_get_msg_seqno(snp_dev); > + > + /* > + * The message sequence counter for the SNP guest request is a 64-bit > + * value but the version 2 of GHCB specification defines a 32-bit storage > + * for it. If the counter exceeds the 32-bit value then return zero. > + * The caller should check the return value, but if the caller happens to > + * not check the value and use it, then the firmware treats zero as an > + * invalid number and will fail the message request. > + */ > + if (count >= UINT_MAX) { > + pr_err_ratelimited("request message sequence counter overflow\n"); > + return 0; > + } > + > + return count; > +} I didn't see a pr_fmt defined anywhere. But, for a "driver", should this be a dev_err()? ... > +static void free_shared_pages(void *buf, size_t sz) > +{ > + unsigned int npages = PAGE_ALIGN(sz) >> PAGE_SHIFT; > + > + if (!buf) > + return; > + > + if (WARN_ONCE(set_memory_encrypted((unsigned long)buf, npages), > + "failed to restore encryption mask (leak it)\n")) > + return; > + > + __free_pages(virt_to_page(buf), get_order(sz)); > +} Nit: It's a bad practice to do important things inside a WARN_ON() _or_ and if(). This should be: int ret; ... ret = set_memory_encrypted((unsigned long)buf, npages)); if (ret) { WARN_ONCE(...); return; } BTW, this look like a generic allocator thingy. But it's only ever used to allocate a 'struct snp_guest_msg'. Why all the trouble to allocate and free one fixed-size structure? The changelog and comments don't shed any light.