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 99968C4332F for ; Sun, 20 Nov 2022 21:44:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F8C06B0072; Sun, 20 Nov 2022 16:44:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 981736B0073; Sun, 20 Nov 2022 16:44:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FB4E6B0074; Sun, 20 Nov 2022 16:44:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6C2406B0072 for ; Sun, 20 Nov 2022 16:44:48 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 191694073D for ; Sun, 20 Nov 2022 21:44:48 +0000 (UTC) X-FDA: 80155150656.25.B57B248 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf25.hostedemail.com (Postfix) with ESMTP id 7D2D7A000E for ; Sun, 20 Nov 2022 21:44:45 +0000 (UTC) Received: from zn.tnic (p200300ea9733e725329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e725:329c:23ff:fea6:a903]) (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 C6D581EC02FE; Sun, 20 Nov 2022 22:34:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1668980051; 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=MU/mPOtQaxPIEiXZaqef4n2ESApESPnWFV9ksNgEQU0=; b=gFsAknCC944e+v3lSc/yaLPJAy9TZ++t5KLypK6/QtbQQV1+nSewg1M/XPNPbe7udjUoKY XkJYWm7M3S2B55bQ82gf5JmgRLTzx9o51DwMSbzF90QR2CE4t51TA++ITub8kM89vDlwYj WqVsyvDAGl5XDyti2GFZL3qEqoO94ZU= Date: Sun, 20 Nov 2022 22:34:06 +0100 From: Borislav Petkov To: "Kalra, Ashish" Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@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, dovmurik@linux.ibm.com, tobin@ibm.com, michael.roth@amd.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org Subject: Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Message-ID: References: <3a51840f6a80c87b39632dc728dbd9b5dd444cd7.1655761627.git.ashish.kalra@amd.com> <380c9748-1c86-4763-ea18-b884280a3b60@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668980686; a=rsa-sha256; cv=none; b=0CNNOQ9u8+l+rplJ9NmTe49RV1qj1Xvgc+xr4rCwBiaQSWOaDydde7101I+OFAPDzaIlWp KrivG8iwXlUCNHTtz7o56Od9GTXN+Hc6WBQtiHDHh5obRxGATsxMcNY+nYxvjp/o6tHSCU 577kmFM+mhSLS0rK2s1O8RH8dgf3cP8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=gFsAknCC; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 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=1668980686; 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=MU/mPOtQaxPIEiXZaqef4n2ESApESPnWFV9ksNgEQU0=; b=lE0SOJlcPs14JAWGc65oHZTghV7Y4n4WxE4BUsnJOlApGC7etrK/xoaUY7SsjTD1xptMCQ zW73nCWFmbxZVQc4+u1xJt/9ir/WreiNBI+xn6J55ajPGrmfLXiHFVZrEdc7m8YtM7+jI8 8rnlxI32A8PsXJsoIeg71ahLyR8Xzj0= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7D2D7A000E X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=gFsAknCC; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Stat-Signature: r1jms6bytncoqtsgkowjskikqshfqghc X-HE-Tag: 1668980685-627411 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 Thu, Nov 17, 2022 at 02:56:47PM -0600, Kalra, Ashish wrote: > So we need to be able to reclaim all the pages or none. /me goes and looks at SNP_PAGE_RECLAIM's retvals: - INVALID_PLATFORM_STATE - platform is not in INIT state. That's certainly not a reason to leak pages. - INVALID_ADDRESS - PAGE_PADDR is not a valid system physical address. That's botched command buffer but not a broken page so no reason to leak them either. - INVALID_PAGE_STATE - the page is neither of those types: metadata, firmware, pre-guest nor pre-swap. So if you issue page reclaim on the wrong range of pages that looks again like a user error but no need to leak pages. - INVALID_PAGE_SIZE - a size mismatch. Still sounds to me like a user error of sev-guest instead of anything wrong deeper in the FW or HW. So in all those, if you end up supplying the wrong range of addresses, you most certainly will end up leaking the wrong pages. So it sounds to me like you wanna say: "Error reclaiming range, check your driver" instead of punishing any innocent pages. Now, if the retval from the fw were FIRMWARE_INTERNAL_ERROR or so, then sure, by all means. But not for the above. All the error conditions above sound like the kernel has supplied the wrong range/botched command buffer to the firmware so there's no need to leak pages. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette