Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d85bf488-9050-13d6-a23b-1440a4df4c81@amd.com>
Date:   Tue, 22 Nov 2022 04:32:18 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR
 allocation when SNP is enabled
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>
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
References: <cover.1655761627.git.ashish.kalra@amd.com>
 <3a51840f6a80c87b39632dc728dbd9b5dd444cd7.1655761627.git.ashish.kalra@amd.com>
 <Y0grhk1sq2tf/tUl@zn.tnic> <380c9748-1c86-4763-ea18-b884280a3b60@amd.com>
 <b712bc81-4446-9be4-fd59-d08981d13475@amd.com> <Y3qdTuZQoDZxUgbw@zn.tnic>
 <cffed3c2-55a9-bdd3-3b8a-82b2050a64af@amd.com> <Y3yhthJTIWqjjAPK@zn.tnic>
From:   "Kalra, Ashish" <ashish.kalra@amd.com>
In-Reply-To: <Y3yhthJTIWqjjAPK@zn.tnic>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3d4WDlGZytIbVk0MjRnNWhweWV1OFZOUm5ic0xMakN1NXczRkJmZlRBL2h1?=
 =?utf-8?B?MW84QTZacjAyN3krc3FUMlpEa0ZVTmxzMmdtM2pSaDFkczVPVzV5aWxpRnla?=
 =?utf-8?B?NTlTWFFBOXNqZ1ducnBkSWVvSi9XRUczN0V6QWE0YlAxQ0lTekhDL1JVdENR?=
 =?utf-8?B?c25ZT2ViYTBQMzF1NEszY2h3ZElhZnlBaUVtZzU4NXI5WUZMcnpxNnZpUmFz?=
 =?utf-8?B?L01VT1pZc1RzckN5aGxBUHFPcjRVdGl1MHpMdHdCaHVJWUZsSjYwMENlTkdh?=
 =?utf-8?B?aDRsa21ZZXNtRmxqb1ZkYlViNGlSM1lsN2hBbjdwTWFaLytXL1VueW5zM0Y3?=
 =?utf-8?B?amp2Z1dVMXAyb1NnZFZnNzhvT0thdURDY0Z1K05velJCK2FiZnF3WFVLNW5T?=
 =?utf-8?B?TUZqZGlYdXFQUmxUYnhEUDhZWGUvQk9aeHJuOU5uYUpxR3p5WTJvbWNaZ1lW?=
 =?utf-8?B?bXVRbE1pQnlJUmdKRWg3anlqQXdOdFBvb3YxZTI4ejBTYm1CUHArME9NS3lJ?=
 =?utf-8?B?RHZhdHozUFBneGwrRmJ0TTA4cjBwcTgwTC83TjIvbk9Vdk8yeFZDelBwMFdx?=
 =?utf-8?B?VTNmK3k4aVN0TVN1WUNuUjdOZU5McG14eVhranVCU2FVOXFBUi9QdURoM1JR?=
 =?utf-8?B?NHFWaUxEKzYvZ3AxOUswL2lWVG94OWRVNG0rU2RtUGlpSUVTdzYxclFYVlZN?=
 =?utf-8?B?VDA3WE50U3p3U2pOeDNFa0src3hFSzFqL29VQ3psRFlLRmlHQjcvK0Nqc1Zp?=
 =?utf-8?B?Y2U3eXlHWEtMSHhnMTYzYkVudHRQNmdqT0FEbDJqaVc0ZlovQnFocElVQ1RL?=
 =?utf-8?B?Ly84TmRSN08zN0g0RzlMV0V6bVF5QXAxeUtFbjhKMmx1cWVJSGNJU2Z4aEND?=
 =?utf-8?B?UGFoL3ZENWJSMmNpU2hlQ1ZSK3ZiUjd0MnZUWm56VDJjZ2FuZnpLWVBxbnha?=
 =?utf-8?B?K1orVUNacDJwWG5XNGJIaHpZVWpCM1UxVXFtU0dHRXVwWnlDdCthanZsNHpr?=
 =?utf-8?B?amd1NE1hcW5KTW5tV0RsTm5iNW1iUVBDcUlVL2V2RzlkcWZ4TGQydWhYTURX?=
 =?utf-8?B?YWZsV1d4SW1oMlBJYTdaYytLMFZXY0ZqKzFGaEtrcEM5NEx6ZVh0UWprV1lx?=
 =?utf-8?B?K0Q3WWU0YXNxaHVIcE5jV2VhVlJZdjNxZWFrbHk4Wjk3UTROL1p6MFJVL3ht?=
 =?utf-8?B?eENsd1hSRFh4Q1R2WkplUmNsdWdERlJzb2tHVG12YzduVWVVYXFoSXk4SUVI?=
 =?utf-8?B?OU4xMVBXU0tTMGNvcWlsU2I5MXdXZ3IvdFVjeDJvQzIvN2VsaVN5cXVHWW1o?=
 =?utf-8?B?OG9YUUNEYitWM1dMT3BycDdycWJzY0t6aTJpMkd5c3BiQVpXT2FDZDdHYWdI?=
 =?utf-8?B?YXdGWjF0SWcvaCtUNGY1N3lsUzVoV3hFNHF0a29TQm10MEhtRlBsSENsZmxM?=
 =?utf-8?B?VUkzOHFna0Q0VEJsRks1U25XNnlQeGZrbnBHS0VHK2hjOCtvSEl2Y294a0VF?=
 =?utf-8?B?S2oyU3lrbnlHQXg0WjNGNWFUQ3FFblpRbzlyT0pORTVYSUcvY2VFM0dhdXdQ?=
 =?utf-8?B?eGM1RjV5YmxOdHZuY3V6NCsrcVBqeWpSVCtnSjN1SW9nV3daOHZMY2tlZmpE?=
 =?utf-8?B?S1M5d3hWQTZjYzlYZ014bUFScFRHd1JxZk0ydmFkWEw4SWQ3QStOY0xaRDJQ?=
 =?utf-8?B?VW1rWUtGc3J1bndSOXZ0SlhUWmVUQTA1MU1TNDFxNjJkRy9aQlR4T0dSVGp5?=
 =?utf-8?B?em84TGlScFRhaUtDdjdsS2N4STI0OXRsd2F0STFoMDk3Vy9ZT2Zzckd5VFdT?=
 =?utf-8?B?bDVtYTRETEJlT05EdC9LOTdiVVVQU2V2RlhjUEs2UmV1WmVIVkt3UDdIN2Er?=
 =?utf-8?B?QldOTlp4TWVVRXNKOHZEdHJSZTZBYWNoZXdwcEpLNEcyU0dKUzFJUjlHQ2RD?=
 =?utf-8?B?dUR2eGJRL3daaWFiT1J1eW5zTEw1cnUza0FJL2xmUEVrUnVteVArRXpSb0k3?=
 =?utf-8?B?bW15b1FoZ2w3VytTLzNkYkdtSzBGeUp2elo1VVBJZWNBWGpWSlozdXhiTHhr?=
 =?utf-8?B?azlPN3FWRmE0U2NtWHlnRGZVREQvMys2QTFGTUh4SThJVkt1S0VJV3ZFdWpS?=
 =?utf-8?Q?CFZDG2VQyIzmwBmC1gERFjwfA?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43a9754d-ed0a-4099-68e3-08dacc74d7e5
X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2767.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2022 10:32:23.8630
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: g6wsz+cqesjPX2+zjOogOrd728GDzpdJ5Lw00TJ7jzC0XuzyBwpoGpqOAIDiAbH1qFRjeSLOjCmreySotHtimg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6608
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

Hello Boris,

On 11/22/2022 4:17 AM, Borislav Petkov wrote:
> On Mon, Nov 21, 2022 at 06:37:18PM -0600, Kalra, Ashish wrote:
>> I agree, but these pages are not in the right state to be released back to
> 
> Which pages exactly?
> 
> Some pages' state has really changed underneath or you've given the
> wrong range?
> 
>> It might be a user/sev-guest error, but these pages are now unsafe to use.
>> So is a kernel panic justified here, instead of not releasing the pages back
>> to host and logging errors for the same.
> 
> Ok, there are two cases:
> 
> * kernel error: I guess a big fat warning is the least we can issue
> here. Not sure about panic considering this should almost never happen
> and a warning would allow for people to catch dumps and debug the issue.
> 
> * firmware error: I don't think you can know that that is really
> the case on a production system without additional fw debugging
> capabilities. Dumping a warning would be the least we can do here too,
> to signal that something's out of the ordinary and so people can look
> into it further.

Please note that in both cases, these non-reclaimed pages cannot be 
freed/returned back to the page allocator. Anytime the kernel accesses 
these pages it will cause a panic or host process crash.

So along with warning, the pages will be added to a leaked pages list, 
but there is no poisoning or anything, only need to ensure that these 
pages are not touched/accessed again.

Thanks,
Ashish

> 
> So yeah, a big fat warning is a good start. And then you don't need any
> memory poisoning etc gunk.
>