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 48F48CDB482 for ; Wed, 18 Oct 2023 02:29:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EE408D012F; Tue, 17 Oct 2023 22:29:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7778D8D011E; Tue, 17 Oct 2023 22:29:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CBD18D012F; Tue, 17 Oct 2023 22:29:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 475228D011E for ; Tue, 17 Oct 2023 22:29:25 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 11CC5C0E73 for ; Wed, 18 Oct 2023 02:29:25 +0000 (UTC) X-FDA: 81357000690.02.CE49504 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2079.outbound.protection.outlook.com [40.107.243.79]) by imf30.hostedemail.com (Postfix) with ESMTP id 0461D80010 for ; Wed, 18 Oct 2023 02:29:21 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=lCjJAKmR; dmarc=pass (policy=quarantine) header.from=amd.com; spf=pass (imf30.hostedemail.com: domain of Alexey.Kardashevskiy@amd.com designates 40.107.243.79 as permitted sender) smtp.mailfrom=Alexey.Kardashevskiy@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697596162; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rdunNkpg1VSqiYJ/aevxDaNiul6VMkZa9I8gV6/jsnE=; b=Wc8qNiE3j1StcDTC9dIjr6X8lHsgEJipSf9xhLIPDrNcWUuXvXi8YRRSlzaC2q0jyimP8o 9vTWVJJ4OKPkK9kOBt6kNGJzUdwQ2VcZIQDqPjMCuCIurnAjw6lt35LnVp3ovPaC+BwsKq 4i0DJNo3wTD0eG/19L+2nVg6/AcrzLg= ARC-Authentication-Results: i=2; imf30.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=lCjJAKmR; dmarc=pass (policy=quarantine) header.from=amd.com; spf=pass (imf30.hostedemail.com: domain of Alexey.Kardashevskiy@amd.com designates 40.107.243.79 as permitted sender) smtp.mailfrom=Alexey.Kardashevskiy@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1697596162; a=rsa-sha256; cv=pass; b=r+/bMpTPhdzUGHx9VagcDzplM/BoMCiFGIdQjJd6MJ0rpZRk6yhvNpZINJpWKV4pio5/Jl pz/t6wscVr/FrAVuTisGTCTaswwW/R7nRoYz1lCiHcplfG2HMozo7buS71IpRvNQmf8V/V fxExNYhNKsSBsdzqzKhCGeTyvOU31aU= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f9rIP5BbP5hWWIZBSTm4Jlzx1IUMRhqa0edVRUhXV8D9zcH3AFP1U1Utmo5mV1xryglVK7a9how/ARGl+Y6u0auWbczuNFS4ecdbNyvJC5gAr+TT6ihFWy1g575Lw/a6f/eG6X9ByLQs6QkxFxGBldUiYwUwlAoZPh24Mx9O8vzZwOKF44m81mVhZ0RVdT8++IwspL960f315lexQxnBFIDkM7I32bPfHTDChQuCGUj1uuR8QsquJuhQ0WCalCFwfl+KSxmChULmHlC9um9TyjxAuBDOXOfyxAQgs8cCfBLw8BmUTlvbXoDbItZyVT/WTokkqC4wFdooJdiaESqJrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rdunNkpg1VSqiYJ/aevxDaNiul6VMkZa9I8gV6/jsnE=; b=lHIe+oncHLapMKs/Wn0E2Pu/7L+UpNxTqMDgUANGUzRazcmuJNh2v1ydQX+Hn2Xy0cWR0Y1CFG8gwgHq0SaR4HBbKoh7Q3gq07VHy9SUVIHuMi1Y58yEezkZmWSzaSqV/zybgxyDu3htxv9cyAhf0+OgUciXL/EDuFctS+1wHEmiOlumDRkO3PHPWyZoIKDD1+jQfVxgdAOOm+zWC65Tr2Ca+oKW5OGaKrWetNqRNaWF9Fl0W8uXerCAGxYPJUcCF/eb9Y5846GimjFYHBJHKuxu/fzJqdSeE4trI8rG0DMc/JcGRSn6m7hVV5Fg7TST95swjYhx1/Z6cQoBpdgYSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rdunNkpg1VSqiYJ/aevxDaNiul6VMkZa9I8gV6/jsnE=; b=lCjJAKmRXMxr+4dy8czH1G4oPaPnPvUxvPBI1XTYP6ZG5WD7rMErvL6Sa2j39qxkOrN3Uxs3+W3TMmpi5GpcBDIT5vAwQyMXD4z3+avse1XIWg3WBJIsP/ZdDOPDToEhbNUAH0jSXXfeDufr+Yf+up8QRHcDIBxvzqMKTUi5KZM= Received: from CH3PR12MB9194.namprd12.prod.outlook.com (2603:10b6:610:19f::7) by BN9PR12MB5292.namprd12.prod.outlook.com (2603:10b6:408:105::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.21; Wed, 18 Oct 2023 02:29:18 +0000 Received: from CH3PR12MB9194.namprd12.prod.outlook.com ([fe80::16da:8b28:d454:ad5a]) by CH3PR12MB9194.namprd12.prod.outlook.com ([fe80::16da:8b28:d454:ad5a%3]) with mapi id 15.20.6863.043; Wed, 18 Oct 2023 02:29:18 +0000 Message-ID: Date: Wed, 18 Oct 2023 13:28:50 +1100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event Content-Language: en-US To: Sean Christopherson , Dionna Amalie Glaze Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@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, 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, bp@alien8.de, 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, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-49-michael.roth@amd.com> From: Alexey Kardashevskiy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SY5P282CA0006.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:208::11) To CH3PR12MB9194.namprd12.prod.outlook.com (2603:10b6:610:19f::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB9194:EE_|BN9PR12MB5292:EE_ X-MS-Office365-Filtering-Correlation-Id: aca489fc-b572-4a17-7ac1-08dbcf82075c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LbmdoO3EzPKqoaRcScNp5kqXmcbqUH6XxayKGhGlhUYOoUcaddZrXDd3mrLx6mWxRKs1+0nEznGDz+xBH3qb3ivKTxrorI/j+TBlBhO7yPy+TIfZTjEqeRZIpd3zRg2dUxd0dY7Xf/qfdKQatOaA7IXbJSNyfrkFii/0aLTYVXpkIKRYW5rHVHX5JdfV6pb2Y/TuZGFHCoS2hZN6Z85iPJJ4TqJ9hrIlP7AtGsCX5xYiWd5WhQrE0/3NdrsSfpOVzIKKYEX+3Vv7GfA4MDXRb7gKDwLwSCaWCeL+RsPcgA7Q6y7RfjZfctpRXXKMdh5iEe8B5j3T53SWRhebJxr1SectWXjgQs4w4EtflsjZgirhtUKE2KUas5ZoIovwH8UAjXewx59QdREjcFxizltau+1UIv+VJFW2m6HkxE7EfTfcrhG7096UAkCindfv6L5cqE8okGHhICnOyI59UPQFlSthZs7jS0gisnpFMkDXOzR9kxWkEc85miULYzj4lnkuerwnZ2BdxaAFTGX+aIlzSgNeJLLmBvJWyHe7pUr/BWlMNASidcb2RQnIkso2MK2g81b16ZXJARjy6v43mOw/CzWc/Yigvfi2ANHY8uQZFDeYnQi84Zk30xbPu6HJZXy1b6Ml1XOiufW2h+VRLOmA6Q== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB9194.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(396003)(366004)(346002)(39860400002)(376002)(136003)(230922051799003)(186009)(64100799003)(1800799009)(451199024)(36756003)(31686004)(66476007)(66946007)(110136005)(54906003)(66556008)(38100700002)(31696002)(53546011)(83380400001)(6666004)(2616005)(26005)(6506007)(6512007)(8936002)(316002)(2906002)(478600001)(6486002)(7416002)(7406005)(5660300002)(8676002)(4326008)(41300700001)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vm5OM08rNkFBR0RZYytSRE13UEhlUlM1K0FJMFNNN3pvZm94eHRJZ0g2SnR1?= =?utf-8?B?UlZUeWo3SWd1MXozL2w0QndPQ0g4T1VPazYxUmRrZS9ndjhhQ25RaSs4dWdH?= =?utf-8?B?dmx5RXRTbDBIWTZEUFI2bFJCR1dXblE3UHkxcnV2NStRak94cjRsL0VCRUpu?= =?utf-8?B?S0daRmxUT09XVThRRm1RTWtaR1pucitqNXVneThobGlZaXdwMzk5N1F1Vk5r?= =?utf-8?B?MzQ5d1ZaN1RMOVByUGlxVFEzQjNoMDk0ZzgxU3BCeHJmYWU3Z0NOSTFGOWtZ?= =?utf-8?B?UlZ6VjNRMlViYUtkdHNHWDVHZVlRVHFqWVErdEdLOWhsRkU2WGtyUWZxZXc5?= =?utf-8?B?RUlrM3lmVm1BR1I1amFoOHoyam9aQVNhaG1FeDZtSG1JbHRCeFNpUTgwekdE?= =?utf-8?B?R3pZeGtXYWU3WldYVGVOQ0s1cTI0bElXQ3hJWVo3QWRwNHQ4OW1PYng1WStM?= =?utf-8?B?UW9pUjZ5MkQ0TGtySEROdzhXV0NVWUt5aUxSclFBZ3BGU1VCeWs5NTlWQnIx?= =?utf-8?B?Tml1blhudUJkbkRZV0FLS242dk9yYzFyWk1sWHRaRWdnMUxiRVZMbk1taVRn?= =?utf-8?B?YTZYTm5kY012Z0NIVkRJelJYYUFOdHRjUkVTallYN2o3U3hqdDRBSWJxcXM2?= =?utf-8?B?MzVIaUx2OWVJN3NYOUVSVEtwd253RU5TdlhwYUVadHl1dm1qKzh4OWFCN2ZW?= =?utf-8?B?ZnEwblRzWG5UdzVUSkpTN3I2MXAyTUNIMHQwMHZ3NFdZUjVpUVhiMHUxNUtD?= =?utf-8?B?Um1wVTZqME1zL1lEWXdqRDM4UWNsTDJkSU8veDJ2ZzAwUlV1ZnhaaVBmTFZF?= =?utf-8?B?dFpLaEhzd1UvTjRxSG03ZXhPSUEyUVRENktQVTByL2ZZYjk4SUoxMGhNSERD?= =?utf-8?B?QkZaYVF5VGVpbmxqYlJjUE5aaVMveDlHK1dITWN2UHo2SW1tNmhXcnJaY2pT?= =?utf-8?B?dWJIbUR1NXU3MmpoVm1IZmFBYW9kb1lnZ2trRzc0aU1rbDRvZXBWaTlzNTQr?= =?utf-8?B?citydFpuK29yVUttMnRKMWxPZkdudTUzMEJ5b1BBbStsNnpvVFpqOXZGZ3lU?= =?utf-8?B?V0w5dEhWd3R0T25KSU9XSFRDRnBRdWhWdFdSVEVveDZ4MnRLTjYyNTZQWWll?= =?utf-8?B?WHRnaDRnUTY3R2ZFM1FSOGVtRmlzRWhwNzNZeUNqbkhhVHhhZlROREVXMUFp?= =?utf-8?B?NVpSTVo5SElBYXlQRW1RTlZQbVA1bHg1ZXJnQ2ZWUXdZd1Rabk5NVTEyamN1?= =?utf-8?B?MkVXaTYxdXhhLzNSS0JzQ1p4RjRDNllKbDcvbE5uVDZCZFZBajdFQjRZZUEw?= =?utf-8?B?UDQ0c210aHQxeUJoRDJ0c1RnU0pmbXRNTll0L3BoWkVMUitIU245cjRyT2I2?= =?utf-8?B?dTBQWDErR01NSnNLZUlBTDg3TzVTMkMyQWMrdVR4SkhnYU1mdmRjZDlETkI0?= =?utf-8?B?eFNjWU05Y2NGSnZzZU4zbytyVzY2TWtUTEo0QklhY29TRm9QQnNNUS9HTlI3?= =?utf-8?B?N2dBS0F0T3d6U2xWbXJhT0Nveld2RG5aRHdJKy9Ob0srQjhQSDZuS00xNkRY?= =?utf-8?B?S3FORzU4djBWZDNmVkxxS2V6UURLem5pZ09IRlRoWHo5YXFGR1pCbW9ITGlG?= =?utf-8?B?S3BnSWVwOW51TG8xS3ZCTzhwa1Z1NFNvUDBTNmhwRFpwWThEaXVLZlVZTmpm?= =?utf-8?B?Q2Y5SVVZcEt1Y3AvSmVieE5pUmpJeiszOGpaNUt2aTRGWHFYejFIK1R2QkFi?= =?utf-8?B?RnlSM0ZLRzJsMmJMeGFVNnZFeWFpSXZmeWxYWUJrQStWNTFFS21GVkM5OEZJ?= =?utf-8?B?MUY0a2JNNUduM3FtVmlhOFZoYkM0ZnJyaGtvMEZQTG9TZGd3YXh3Rk9SZnd0?= =?utf-8?B?cTdaaDlmNlVaT0VkSmtJc2x0cGx1UnNnYVI3elAxR2MwTWdseUViK3ltUG9v?= =?utf-8?B?NW4zMnd0K0pBOERtamxJNnl6cmcvQkJWVm93STZMcHRTUUZzWjdlOWFPWWJP?= =?utf-8?B?a3IvOTJBYmpiQzQrODRaL25IUkhvSUpEQTRRS1RJb3ZpcXhtRHhxT29pYngv?= =?utf-8?B?TkllY3lFeEhwUWxQaTJ3UVg5bEUxNmN5Z3VxSnRHQ29UOE4wQTZydWNNckxB?= =?utf-8?Q?m1PYd3hdcOg68yb74h9LZ4X6t?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: aca489fc-b572-4a17-7ac1-08dbcf82075c X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB9194.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2023 02:29:18.2565 (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: qhtNQlgh8nOAm1RVarS+kyNvIFvEraSvZW1T7W59XmKoE6qH1KHZm6sph9gfhglEjghbDrmWWMsKSEEqQaRUZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5292 X-Rspamd-Queue-Id: 0461D80010 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5yj6k3uyfr155mzqbwrho6gw8m5yoap1 X-HE-Tag: 1697596161-930029 X-HE-Meta: U2FsdGVkX19uB5dl34xihsDuWVPDE76y1QamL9NhfBR0arB2J8j7n46ksQ0hKEU4hbvI130Oobo2DhfYTi5plAt+5b8p1M1/ZKa2NjG4fulbl7x1KUBr8ILUTKgtal43P6s4R3/qSnnWRjHasByYi6cnMr1EnDeJ4Rae4OyhvTaV6ichgW1sBNY4sPYw/EttFJ/9NrX5x0EorMRmipGZetua4pulCHm9n8otPscW+4xhcwiOS50slBjr7c6x/uRy0SH0DFWjC6PLJlx68J/uGw6iniYgguivHjK0N81J7Tdvdlag1Vu4Qc6Iz3TPRvWn/1xZnvug5SWfjFG+vnzU4Q82DS0qLSLtamurvpHafLuv6katiTVn6RGiP0tuhT23FCWcpBmHsiB3p/u1IqypkUy2KzNJkDH74PcVqFCtRwq7yRtfiBvCOFfXM0LijFvP244i2bzEOaAMCy7ECdMQ/bNt8b2h7NS35gYDWgFdp3g1pWIOMv/e8a3eCZ/rcvcXgbV39PxmkCn9Kh/MZ0ImlkxgnBWifCAkcOLPDuU65b/0ATOCiA1VxX26xEsF0TieRvXZc4zRvtllIXyqHEWKGYbGHOaChp5abyKvZvbzRBCpm0sjbok3GEw5BdXC+aFgslGv1FJmRCjQJIrhLb+FgNij1h6lFgwMYmS7ydGGz2w8G3RhzaQEklXoLJB2jvmlX9747FAD4WbOJ6A8kTF/i4jXmo0fyqLux/8UFqcEaaZCracqM528o/eM/p1aYDKf6P1jXWPDGQbdS+6v5M7JUq8S/Tnm+TPM6t0TuMjcxrb/tergKSFLOHoksSvjuJHt2RF2E168GHGQGMwnzzW4TQ0Wjs60qIP7rkcOxDpMqAL+/cu62yS3dVmpP57mpv7ueiSrILUqSCltiJIJ1TDz2VGB/8Dwlh2MQ1kM/to4vQW1BZ8zNoAbfKJ42yQzj7bqexrBcGy2Shn19JXCpLp Usix6YyL sO9/MIp5+sCACCLqWqTX2Ct3PmqBetrDrqpJTTdFvW3yHHH6S/h+bfbdrho5U3aU+mBNotRkQU9bZoc6Ba+30r6iLKX7+rEu7r4kHFivy+MTUP/qEBSWv/Mb3VGXYHSphFOeYCU1IzBhx/HVx3i1OWvetozArKWoM4SuGDIwRiEI7wleFJSDH0c0sVzjyVIVC4i6B0ipB2aYA5Y4LAPoAT+cH2AzAFJVqVCbG9duZ9OS6EUNqP0VVjezZiMHZCbno4dWPnoTyjfHo1wRgnWmOAgPbfCwptR7rGFht1tUn6xMFGyps1JmqzhDkf6OYNZprVj4EmfyBLK0ztLvgZziGAZWnOqmOD+subvZn4umhbQs+d5MOzqkb9eUhSY34otnwnKquEkvZpqFjDVyV8uSTqGMsS7LFXMHswOTmMBi2x0y3rLngBoPngtX3vQ== 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 18/10/23 03:27, Sean Christopherson wrote: > On Mon, Oct 16, 2023, Dionna Amalie Glaze wrote: >>> + >>> + /* >>> + * If a VMM-specific certificate blob hasn't been provided, grab the >>> + * host-wide one. >>> + */ >>> + snp_certs = sev_snp_certs_get(sev->snp_certs); >>> + if (!snp_certs) >>> + snp_certs = sev_snp_global_certs_get(); >>> + >> >> This is where the generation I suggested adding would get checked. If >> the instance certs' generation is not the global generation, then I >> think we need a way to return to the VMM to make that right before >> continuing to provide outdated certificates. >> This might be an unreasonable request, but the fact that the certs and >> reported_tcb can be set while a VM is running makes this an issue. > > Before we get that far, the changelogs need to explain why the kernel is storing > userspace blobs in the first place. The whole thing is a bit of a mess. > > sev_snp_global_certs_get() has data races that could lead to variations of TOCTOU > bugs: sev_ioctl_snp_set_config() can overwrite psp_master->sev_data->snp_certs > while sev_snp_global_certs_get() is running. If the compiler reloads snp_certs > between bumping the refcount and grabbing the pointer, KVM will end up leaking a > refcount and consuming a pointer without a refcount. > > if (!kref_get_unless_zero(&certs->kref)) > return NULL; > > return certs; I'm missing something here. The @certs pointer is on the stack, if it is being released elsewhere - kref_get_unless_zero() is going to fail and return NULL. How can this @certs not have the refcount incremented? > If allocating memory for the certs fails, the kernel will have set the config > but not store the corresponding certs. Ah true. > ret = __sev_do_cmd_locked(SEV_CMD_SNP_CONFIG, &config, &argp->error); > if (ret) > goto e_free; > > memcpy(&sev->snp_config, &config, sizeof(config)); > } > > /* > * If the new certs are passed then cache it else free the old certs. > */ > if (input.certs_len) { > snp_certs = sev_snp_certs_new(certs, input.certs_len); > if (!snp_certs) { > ret = -ENOMEM; > goto e_free; > } > } > > Reasoning about ordering is also difficult, e.g. what is KVM's contract with > userspace in terms of recognizing new global certs? > > I don't understand why the kernel needs to manage the certs. AFAICT the so called > global certs aren't an input to SEV_CMD_SNP_CONFIG, i.e. SNP_SET_EXT_CONFIG is > purely a software defined thing. > > The easiest solution I can think of is to have KVM provide a chunk of memory in > kvm_sev_info for SNP guests that userspace can mmap(), a la vcpu->run. > > struct sev_snp_certs { > u8 data[KVM_MAX_SEV_SNP_CERT_SIZE]; > u32 size; > u8 pad[]; > }; > > When the guest requests the certs, KVM does something like: > > certs_size = READ_ONCE(sev->snp_certs->size); > if (certs_size > sizeof(sev->snp_certs->data) || > !IS_ALIGNED(certs_size, PAGE_SIZE)) > certs_size = 0; > > if (certs_size && (data_npages << PAGE_SHIFT) < certs_size) { > vcpu->arch.regs[VCPU_REGS_RBX] = certs_size >> PAGE_SHIFT; > exitcode = SNP_GUEST_VMM_ERR(SNP_GUEST_VMM_ERR_INVALID_LEN); > goto cleanup; > } > > ... > > if (certs_size && > kvm_write_guest(kvm, data_gpa, sev->snp_certs->data, certs_size)) > exitcode = SEV_RET_INVALID_ADDRESS; > > If userspace wants to provide garbage to the guest, so be it, not KVM's problem. > That way, whether the VM gets the global cert or a per-VM cert is purely a userspace > concern. The global cert lives in CCP (/dev/sev), the per VM cert lives in kvmvm_fd. "A la vcpu->run" is fine for the latter but for the former we need something else. And there is scenario when one global certs blob is what is needed and copying it over multiple VMs seems suboptimal. > If userspace needs to *stall* cert requests, e.g. while the certs are being updated, afaik it does not need to. > then that's a different issue entirely. If the GHCB allows telling the guest to > retry the request, then it should be trivially easy to solve, e.g. add a flag in > sev_snp_certs. If KVM must "immediately" handle the request, then we'll need more > elaborate uAPI. -- Alexey