From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazon11012049.outbound.protection.outlook.com [52.101.53.49]) (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 BC5423A1E88 for ; Thu, 26 Feb 2026 13:59:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.53.49 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772114392; cv=fail; b=R1JrqhDQZ+iQf1o0edcpDyUCnwi2WpK8dI5CQXdBQ7hEtJh46sXUZDs0qOHTPr0/PFAo9r7J9/Ho/dQDVHsV/JLUz5WzjCh2pVaBPSNA5j1WHi7OzpoW46glQ0ywetZ4kwF9ogEz+78y/0LHkZ05oNFpNdDSlwVPh3tDdqQVQK4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772114392; c=relaxed/simple; bh=5GOfhqapXUlKVvVno5lE8Oc/TfXZvaUaWFZHuiVWAYU=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=IIfon5ehU/VZ0wZ7R8Gb4b7mO82eWlcG0sooPw/YjH0SdPUbS59nSNp2ir4NHE2fBLxLmGj3IvEZJ79DhIGFdd6z8oub8Q1YmBConwBfsbruLsAXXv/Izvt7Gx3aeH4yLBwk9UIFnoOnIK8dhxwQ3VCwvnPC7k1kbuBC7MgUkd4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=GYAEbZm4; arc=fail smtp.client-ip=52.101.53.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="GYAEbZm4" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qrhMDUku+2KhI+vRnLg4rh3bADi5HhlbxBMsWzsaAVCS1wuAcqcT7FAH3/Wr6V0/6sV+yGjZFUorDHauJxnjF7kqxK7MCxpcpPliwUycVDuuIu+fJM1olLxRnd/1nNx7sr+pu+6pbj8ruBeW/DlMQyIttfOZnb/5Jh9tzQW6PElxdC3SU7z3J3JOlGPkltFrDkGZDZW1GBOXK0lpSCYLn1deMALZQ47P5s1tJDALS9fXqNQmPjat3EiSD3H6OMKfGsd32rm63pEySC4mHOudKRqaBraI1vjPOMhyYPeuXxpiMnKu3zmRuuOYSM8eENQTDkf1Gkxl/k7Cp24A0fIhAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=WeBQVOTsker2Z77408VQpEzyjCMNTaU3zFdcA3af5M8=; b=IiczTwlhwZ/OP0CsMgn9BOaY1TAjaljA/Eyx5YwlqZfBWRQe612JHoDMpT85WZy98H4qEbxJuD8yslnTrmJ5Xa91OCiHF+KJML969k0sMjKs5UcCNLEqk6wHmpkJfay7xd+0lbJXclwWWgoPS4kagxpalc8hW95Kx8kLDuEVQLbfrpAl9XA+H3DUtvkk3+7U6J0949KIc0r1jLLP6kVxcTwZb9FEASeCl1x4yWAkKeN2Vbo3wuMW6D/VaXoaxC+v5K3xAGBQZvpIQiO0XjGCf7ewkM7RqmIbfBMKKXITKTd0Xu3/lY3vwyiPTOEXxz00tQX7W7mmFhKbnyMQGvikIQ== 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=WeBQVOTsker2Z77408VQpEzyjCMNTaU3zFdcA3af5M8=; b=GYAEbZm4VJDr9fqKm2mrAEap/RQYNefZWTtkglCu+6anxUGGE+6/nv0TgACQoY9JqtJUxzYrbH4hfEwKRByVL8L44TJ94cHIWN6wngdJJj1Z6lMcgEXKqrPPnAZsVrwTPWwPfbs+TZiuaUdw//dqKdBiRARHTEmcVu0yHSPOJew= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from DM4PR12MB5070.namprd12.prod.outlook.com (2603:10b6:5:389::22) by MN2PR12MB4374.namprd12.prod.outlook.com (2603:10b6:208:266::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.14; Thu, 26 Feb 2026 13:59:40 +0000 Received: from DM4PR12MB5070.namprd12.prod.outlook.com ([fe80::f3f2:852c:78d5:9353]) by DM4PR12MB5070.namprd12.prod.outlook.com ([fe80::f3f2:852c:78d5:9353%4]) with mapi id 15.20.9654.014; Thu, 26 Feb 2026 13:59:40 +0000 Message-ID: <4c134316-2de3-45c4-adfb-826eff06d66c@amd.com> Date: Thu, 26 Feb 2026 07:59:31 -0600 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] x86/boot: Fix early boot SEV-SNP panic in direct kernel boot To: Changyuan Lyu , Ard Biesheuvel , Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kishon Vijay Abraham I , Neeraj Upadhyay , linux-kernel@vger.kernel.org References: <20260226060714.1636773-1-changyuanl@google.com> From: Tom Lendacky Content-Language: en-US Autocrypt: addr=thomas.lendacky@amd.com; keydata= xsFNBFaNZYkBEADxg5OW/ajpUG7zgnUQPsMqWPjeAxtu4YH3lCUjWWcbUgc2qDGAijsLTFv1 kEbaJdblwYs28z3chM7QkfCGMSM29JWR1fSwPH18WyAA84YtxfPD8bfb1Exwo0CRw1RLRScn 6aJhsZJFLKyVeaPO1eequEsFQurRhLyAfgaH9iazmOVZZmxsGiNRJkQv4YnM2rZYi+4vWnxN 1ebHf4S1puN0xzQsULhG3rUyV2uIsqBFtlxZ8/r9MwOJ2mvyTXHzHdJBViOalZAUo7VFt3Fb aNkR5OR65eTL0ViQiRgFfPDBgkFCSlaxZvc7qSOcrhol160bK87qn0SbYLfplwiXZY/b/+ez 0zBtIt+uhZJ38HnOLWdda/8kuLX3qhGL5aNz1AeqcE5TW4D8v9ndYeAXFhQI7kbOhr0ruUpA udREH98EmVJsADuq0RBcIEkojnme4wVDoFt1EG93YOnqMuif76YGEl3iv9tYcESEeLNruDN6 LDbE8blkR3151tdg8IkgREJ+dK+q0p9UsGfdd+H7pni6Jjcxz8mjKCx6wAuzvArA0Ciq+Scg hfIgoiYQegZjh2vF2lCUzWWatXJoy7IzeAB5LDl/E9vz72cVD8CwQZoEx4PCsHslVpW6A/6U NRAz6ShU77jkoYoI4hoGC7qZcwy84mmJqRygFnb8dOjHI1KxqQARAQABzSZUb20gTGVuZGFj a3kgPHRob21hcy5sZW5kYWNreUBhbWQuY29tPsLBmQQTAQoAQwIbIwcLCQgHAwIBBhUIAgkK CwQWAgMBAh4BAheAAhkBFiEE3Vil58OMFCw3iBv13v+a5E8wTVMFAmkbaKgFCRZQah8ACgkQ 3v+a5E8wTVPFyg//UYANiuHfxxJET8D6p/vIV0xYcf1SXCG78M+5amqcE/4cCIJWyAT3A1nP zwyQIaIjUlGsXQtNgC1uVteCnMNJCjVQm0nLlJ9IVtXxzRg0QKjuSdZxuL5jrIon4xW9hTJR 94i2v3Fx5UWyP2TB6qZOcB0jgh0l01GHF9/DVJbmQlpvQB4Z1uNv09Q7En6EXi28TSv0Ffd1 p8vKqxwz7CMeAeZpn5i7s1QE/mQtdkyAmhuGD12tNbWzFamrDD1Kq3Em4TIFko0+k5+oQAAf JFaZc1c0D4GtXwvv4y+ssI0eZuOBXapUHeNNVf3JGuF6ZPLNPAe5gMQrmsJinEArVYRQCuDA BZakbKw9YJpGhnSVeCl2zSHcVgXuDs4J2ONxdsGynYv5cjPb4XTYPaE1CZH7Vy1tqma8eErG rcCyP1seloaC1UQcp8UDAyEaBjh3EqvTvgl+SppHz3im0gPJgR9km95BA8iGx9zqDuceATBc +A007+XxdFIsifMGlus0DKPmNAJaLkEEUMedBBxH3bwQ+z8tmWHisCZQJpUeGkwttD1LK/xn KRnu8AQpSJBB2oKAX1VtLRn8zLQdGmshxvsLUkKdrNE6NddhhfULqufNBqul0rrHGDdKdTLr cK5o2dsf9WlC4dHU2PiXP7RCjs1E5Ke0ycShDbDY5Zeep/yhNWLOwU0EVo1liQEQAL7ybY01 hvEg6pOh2G1Q+/ZWmyii8xhQ0sPjvEXWb5MWvIh7RxD9V5Zv144EtbIABtR0Tws7xDObe7bb r9nlSxZPur+JDsFmtywgkd778G0nDt3i7szqzcQPOcR03U7XPDTBJXDpNwVV+L8xvx5gsr2I bhiBQd9iX8kap5k3I6wfBSZm1ZgWGQb2mbiuqODPzfzNdKr/MCtxWEsWOAf/ClFcyr+c/Eh2 +gXgC5Keh2ZIb/xO+1CrTC3Sg9l9Hs5DG3CplCbVKWmaL1y7mdCiSt2b/dXE0K1nJR9ZyRGO lfwZw1aFPHT+Ay5p6rZGzadvu7ypBoTwp62R1o456js7CyIg81O61ojiDXLUGxZN/BEYNDC9 n9q1PyfMrD42LtvOP6ZRtBeSPEH5G/5pIt4FVit0Y4wTrpG7mjBM06kHd6V+pflB8GRxTq5M 7mzLFjILUl9/BJjzYBzesspbeoT/G7e5JqbiLWXFYOeg6XJ/iOCMLdd9RL46JXYJsBZnjZD8 Rn6KVO7pqs5J9K/nJDVyCdf8JnYD5Rq6OOmgP/zDnbSUSOZWrHQWQ8v3Ef665jpoXNq+Zyob pfbeihuWfBhprWUk0P/m+cnR2qeE4yXYl4qCcWAkRyGRu2zgIwXAOXCHTqy9TW10LGq1+04+ LmJHwpAABSLtr7Jgh4erWXi9mFoRABEBAAHCwXwEGAEKACYCGwwWIQTdWKXnw4wULDeIG/Xe /5rkTzBNUwUCaRto5wUJFlBqXgAKCRDe/5rkTzBNUw4/EAClG106SeHXiJ+ka6aeHysDNVgZ 8pUbB2f8dWI7kzD5AZ5kLENnsi1MzJRYBwtg/vVVorZh6tavUwcIvsao+TnV57gXAWr6sKIc xyipxRVEXmHts22I6vL1DirLAoOLAwWilkM+JzbVE3MMvC+cCVnMzzchrMYDTqn1mjCCwiIe u5oop+K/RgeHYPsraumyA9/kj8iazrLM+lORukCNM7+wlRClcY8TGX+VllANym9B6FMxsJ5z Q7JeeXIgyGlcBRME+m3g40HfIl+zM674gjv2Lk+KjS759KlX27mQfgnAPX4tnjLcmpSQJ77I Qg+Azi/Qloiw7L/WsmxEO5ureFgGIYDQQUeM1Qnk76K5Z3Nm8MLHtjw3Q7kXHrbYn7tfWh4B 7w5Lwh6NoF88AGpUrosARVvIAd93oo0B9p40Or4c5Jao1qqsmmCCD0dl7WTJCboYTa2OWd99 oxS7ujw2t1WMPD0cmriyeaFZnT5cjGbhkA+uQGuT0dMQJdLqW3HRwWxyiGU/jZUFjHGFmUrj qFAgP+x+ODm6/SYn0LE0VLbYuEGfyx5XcdNnSvww1NLUxSvuShcJMII0bSgP3+KJtFqrUx9z l+/NCGvn/wMy6NpYUpRSOmsqVv0N71LbtXnHRrJ42LzWiRW2I5IWsb1TfdMAyVToHPNaEb0i WiyqywZI5g== In-Reply-To: <20260226060714.1636773-1-changyuanl@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: CH0PR03CA0328.namprd03.prod.outlook.com (2603:10b6:610:118::14) To DM4PR12MB5070.namprd12.prod.outlook.com (2603:10b6:5:389::22) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR12MB5070:EE_|MN2PR12MB4374:EE_ X-MS-Office365-Filtering-Correlation-Id: cf6794bf-eb8a-4054-ddbf-08de753f492b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: Re+UtSOiJrhgq715XLzeSAP0f9k+6NtSm+qqvNvQDv982Abm0zc63+Da4CwABwAJ1DVMIIpW7isPaZPHadVRT6nJbs+TIanNk70lguaX+/B3Fh+9+Vir7P9iVDH39yKnorQ+aay3SGmrKwUlxD1HOFCTolfqEN8z9fBsemwJXOkTOoCZvP8rFidEQoEcfV0zG1Gh0ANCFP2o3uZPL9qcCsAIwXiCb6UKTMCs9FiRLtf6o535Ir0P9KorjFbxVr8aXD8wi/qA9mv9fbt8hS3G+OXRoUIFZzwYMrZDtxQRldlmOZD2D9OKBTt7SYZEAuMPG7byc10Qi/suWEPBVlstsYGuyn3je+uDVxHe9sZO0v41dT1uVu6TQ8T3XrNMXXWKzpJnbz2tLg+psb7XzjrcIHIjMkv0QPAy83poSDDncLYachJv08cNcXvvc27aU065GfpzjrZN331NrKJvKIbJXFySvLimc+VL0PPTnZnXs8OvXnnlZKPA6mzvNdCXZnL4q+tcG3HvqygE1U5GT6nivtEoe25K26DgkQuS+SKmVW58M/XsFPnWRQDTjV9H+MHecx5WWDEYKuOsTE2TbTeBQ6QbUKFwc8vrta8AYhQmjrQa0q6QL595iy8PrpS4K5iAw91kmhsC2UQ3L0klkqb6m89yy0CxCNlD+fbzSQQXgU28311Vzs663G0B6vB8RvrK X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5070.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eFFYWmRXQnhicnZVRmNFUWozeEdZaWk4OTc5R1FncVgrdnlqUE9aYzNCc1Fh?= =?utf-8?B?R0tWUDhUQStKcUdqY08rM3IyWjg0LzB0cFBVelFZSi9DMUhtMWMrblp3VE5m?= =?utf-8?B?ZzVDRDhGejBWQjNoaTJkZlo0WWh0TE52NnJUaGVCS3lFVWhGbE1PSWUrWGts?= =?utf-8?B?QnpEdzU5V0NHN0VOeEZIZDkzMzJtUjlEM1YrZjN4VTBnOElJaWxROEYvQnFq?= =?utf-8?B?ZEVnZXVoQUMySmpBY2ZPTXVuYkpkYWhacjRsREdGOE9VRkExMjRndTdvUVZT?= =?utf-8?B?Q0VmOVg1WFoyazZSOXNxZHZoRmMvbWtkRFdaSUM4Ly9jNFgwdys0R0JKQ2ZP?= =?utf-8?B?OVgyU1dqVW9FMVdsbUducUFXTFBVdVBWR3M4Z1dCbjFSL01jbys3VTVTamJK?= =?utf-8?B?djVXQ0IrTCt2OUE3dHcwREdVdHY4RThjd2R0Zm9GYnc0MFd1bXBrYzkvdjRQ?= =?utf-8?B?dFNEeTg0VkVKNjArYzRBcWdXN3NHQThrTmxldUZEQkY0bW5ZN3U2UitUN0kw?= =?utf-8?B?MDdtc1JTZzdUSHFaMkdqRlNUNmI0VVExTEtwSFMrVjM0NDgxcFZadzJqNjVB?= =?utf-8?B?YndQcitTVzBtOVJOeEpBaFNUUVlLalZEdkVRZ2J4eElreUpRZHZQcWJ0b2F3?= =?utf-8?B?WlNUSlZVTWNyZ2g4RmdQWDFjMkRYditIS3o0bzNVNXU2MXVaVTdrc29UYmZp?= =?utf-8?B?NytNUURmZnVBYmo2Z2V5VjZuT0taWHJIaXlGSm5pM0JpcHlnUExoT0FUcVlh?= =?utf-8?B?VE4rNmJLY0JyTHpnUVVLY241U2ZOTi9NN0NXVWpyRWdHaVlodGZjM0I3OUZR?= =?utf-8?B?d2ZvTWxCZ3BSdDNtOTZ0UWVRMjlnQVdTOTBYRGkrNVBNNlVJY3RiZ1Zzcnk5?= =?utf-8?B?d0xuakEvS0NkUkY4eGxzUTNBL1JlYms5ZFFCR01BZUVkYjhWZTBvb0Y0c09T?= =?utf-8?B?VC9YbUN1b1ZlOXZVczNtMFdVVy9zZkNRYng0ZXI5ZWdpWkhjNmxkSnVEREhO?= =?utf-8?B?ZGd0dkZXbkZERCtSa2NCSkloUEVBQjNwTUZkMmVWQlFndXJFbmFJQnJXNTJv?= =?utf-8?B?d00xaGh5djFOUlEvUmZEQnNmRkdTQXJsSUc4dGFVc2p5alZxSi9yeFBKVnVS?= =?utf-8?B?akwrZGV0RGxNQm04MlRzU3NKVVB5NXZROVh3TWU5Rmxkck1KZHByNWlzTHN5?= =?utf-8?B?YlZQb3gya1B5UTB5bDBoMlFmODZSenM4akM0c0JUeWFZRlJRQ0RPUWZpTDIr?= =?utf-8?B?NkoxZEFMSE42cnNvS2NKTmp6WGQxRkhQOHZLNDlkc0xSYjVTWklnb0xUaFlx?= =?utf-8?B?MEcxeVhTckgzMGszazJtOEVpckk5RmlUK29QSGREQzhnNExybkVnRDMyZWdy?= =?utf-8?B?d2NSV09KZHY3WVBRNzBKQ2dFUlRVdkRZRVh5ZUVRVEZFZDcvelRmSjRKeDJK?= =?utf-8?B?bDljR3N4QXhVNWRza2VCSDQ5ZmIwMDgrMkJocWlDeUorWkRyUFlHRWdFRlBt?= =?utf-8?B?ZnhCWlEzMTZpREpaaFlLK095YUl6REJYdFFlbms3V0dvZHJHTUpRb3VrL1hr?= =?utf-8?B?MVV4VE1CbGF1NXhHcGliQlM2cDhUSGlwbXQwb1h6RmpZbjBoM1RhVklkLzBu?= =?utf-8?B?S21Ja3huSCtGTW9aNkRkUWVtV2VpRXorS2oyVzl0eXVSNWRWb1BJU014NSt0?= =?utf-8?B?YzcvUHhobGoycGowM0F2OW94M3daUjN4bEdHb2JXK1A2bG9nL1lwbHRabjZy?= =?utf-8?B?bXRDTzhCeEtVbGdKR3FqanNYN1lRY3gxeVlhOFFES1c4eUtWSVZhUWFoMTlF?= =?utf-8?B?UFlnZHZVc20zb1I1YXhUaWVhWVJnNGRtOWRlOFY4akxUNVpNUFd2VFVNT1JN?= =?utf-8?B?TTltUElCL1BEVW1TUitJMytCMnVoWnFRQXd6UXZPQmJGNDBLcWpRQURVWG5s?= =?utf-8?B?NzJFdUdUbnhiNXdkVmpLSFJRakpFclk3R2g3clJETHdaYWJsOWNNNzlTelFO?= =?utf-8?B?ZmkzSU11em1pemgwUm0vMUVINHRNN1E4Y0x4REhmQzdkWm5VUlZGQm0yb0k5?= =?utf-8?B?dDNFSDRwQmtEbDBBKzY4bjF5Y3pMN3d5Y3dUOTRnejhPNmpnd0RubStYQ25G?= =?utf-8?B?QWdqTm9jTU9jUUFnYTVLVUNwTGdJdysrc1ZTbWNxRmNXKzMrMEg2V2Jlbkt2?= =?utf-8?B?VW05SzA4ZnlkYWsyV1FJU3Exd3FtMDZqTzFPZEtMcm1DQWF4YUt3dDU5MWg2?= =?utf-8?B?eXlsUmh3Tkkwakd6NUJNakhPZmRuWmFseGM1VUpITC9MNENoT0V5YWM1MHVI?= =?utf-8?B?QVRWR1VPMy9kb1FJamFuaytEckFPTmtBcUl3Ui9CYlg4eVU0Rms1dz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf6794bf-eb8a-4054-ddbf-08de753f492b X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5070.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2026 13:59:40.6076 (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: FVpHB44T3N7BQXH1kflciPCm3QfeL4KSeuX46QditT2E2de38YCU3Pj7N4g2tgfsdUGlQMClJyjy/zGUbSo3GA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4374 On 2/26/26 00:07, Changyuan Lyu wrote: > Hi all, > > I'm writing to report a regression introduced by commit 68a501d7fd82 > ("x86/boot: Drop redundant RMPADJUST in SEV SVSM presence check") and > to request feedback on the best approach to fix it. I submitted this back on Feb 4th... but it was close to the merge window so it wasn't picked up at that time. Please review and comment. https://lore.kernel.org/lkml/5648b7de5b0a5d0dfef3785f9582b718678c6448.1770217260.git.thomas.lendacky@amd.com/ Thanks, Tom > > == The Bug == > > Commit 68a501d7fd82 ("x86/boot: Drop redundant RMPADJUST in SEV SVSM > presence check") introduced a regression that causes SEV-SNP guests > to panic during early boot under specific booting conditions. > > By design, snp_vmpl should only be assigned a non-zero value when a > Secure VM Service Module (SVSM) is enabled and the guest is running > at a VMPL other than 0. The commit refactored the VMPL0 enforcement > check in sev_enable() to rely exclusively on this variable: > > if (snp_vmpl && !(hv_features & GHCB_HV_FT_SNP_MULTI_VMPL)) > sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0); > > This panic specifically manifests when there is *no* SVSM present, > and the kernel is booted via a direct kernel boot rather than the EFI > stub. When booting via the EFI stub > (drivers/firmware/efi/libstub/x86-stub.c), the environment and zeroed > memory are set up by the EFI loader before calling sev_enable(). > > However, lightweight firmwares—such as Project Oak's stage0 > (https://github.com/project-oak/oak/tree/main/stage0_bin)—jump straight > to the kernel's 64-bit entry point following the 64-bit Linux boot > protocol, bypassing the EFI stub entirely. During this direct boot > path, head_64.S calls sev_enable() exceptionally early in the compressed > kernel boot sequence, significantly before the .bss section is cleared > by the rep stosq routine in .Lrelocated. > > Because snp_vmpl is declared as an uninitialized global (u8 snp_vmpl;), > it is placed in the .bss section. When sev_enable() reads it during a > direct boot, the memory contains uninitialized garbage data. If this > garbage data happens to be non-zero, the kernel erroneously assumes it > is running at a non-zero VMPL. Because there is no SVSM present, the > guest forcefully terminates itself. > > == Reproduction == > > The issue was reproduced and tested on an AMD EPYC 7B13 64-Core Processor. > The stage0_sev.bin firmware used for testing can be built from > https://github.com/project-oak/oak/ via: > > $ bazel build //stage0_bin:stage0_bin > > 1. Reproducing with QEMU: > > $ ./qemu-system-x86_64 -nodefaults -nographic -vga none \ > -M q35,confidential-guest-support=cgs \ > -accel kvm,kernel-irqchip=split \ > -bios stage0_sev.bin \ > -append "console=ttyS0" \ > -initrd initramfs.linux_amd64.cpio \ > -kernel ./vmlinuz-x86 \ > -m size=1024m \ > -smp 2 \ > -serial stdio \ > -cpu host,x2apic \ > -object sev-snp-guest,id=cgs,cbitpos=51,reduced-phys-bits=1 > > QEMU panic log: > > stage0 INFO: jumping to kernel at 0x0000000002000200 > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00a00f11 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 > EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ... > Code=c5 5a 08 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6d f0 00 00 00 00 00 00 00 00 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? > > 2. Reproducing with Alioth (https://github.com/google/alioth): > > $ ./alioth --log-to-file -l trace boot \ > --cmdline "console=ttyS0" \ > --kernel ./vmlinuz-x86 \ > --cpu count=2 \ > --initramfs initramfs.linux_amd64.cpio \ > --memory size=1g,backend=memfd \ > --coco snp,policy=0x30000 \ > --firmware stage0_sev.bin > > Alioth panic log: > > stage0 INFO: jumping to kernel at 0x0000000002000200 > Error: VM did not shutdown peacefully > 0: Failed to handle VM exit: KvmRunExitSystemEvent { > type_: KvmSystemEvent(0x6), > flags: 0x31100, > }, at alioth/src/hv/kvm/vcpu/vmexit.rs:84:14 > 1: Failed to run VCPU-0, at /alioth/src/board/board.rs:381:46 > 2: VCPU-0 error, at alioth/src/vm/vm.rs:275:25 > 3: VM did not shutdown peacefully, at alioth-cli/src/boot/boot.rs:474:15 > > == A simple fix == > > I tried moving snp_vmpl to .data: > > diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c > index c8c1464b3a56e..a1a1cb47e7b93 100644 > --- a/arch/x86/boot/compressed/sev.c > +++ b/arch/x86/boot/compressed/sev.c > @@ -35,7 +35,7 @@ struct ghcb *boot_ghcb; > > #define __BOOT_COMPRESSED > > -u8 snp_vmpl; > +u8 snp_vmpl __section(".data") = 0; > u16 ghcb_version; > > u64 boot_svsm_caa_pa; > -- > > I tested locally with this approach, and both VMMs can boot the kernel > successfully. > > However, Gemini identified that this approach breaks SVSM guests due to > how the decompressor handles the .bss section during relocation. Below > is its analyses. > > == The Complication (.bss wiping) == > > The seemingly obvious fix is to move `snp_vmpl` to `.data` (e.g., > `u8 snp_vmpl __section(".data") = 0;`). However, doing this alone breaks > SVSM guests due to how the decompressor handles the `.bss` section > during relocation. > > At .Lrelocated in arch/x86/boot/compressed/head_64.S, .bss is wiped to 0. > Currently, for SVSM guests, both snp_vmpl and boot_svsm_caa_pa (which are > populated in sev_enable()) are wiped to 0. The kernel accidentally survives > this wipe because extract_kernel() later calls early_is_sevsnp_guest(), > which contains a fallback: > > if (!snp_vmpl) { > /* ... CPUID checks ... */ > raw_rdmsr(MSR_SVSM_CAA, &m); > boot_svsm_caa_pa = m.q; > snp_vmpl = U8_MAX; > } > > Because snp_vmpl was wiped to 0, this fallback triggers and successfully > recovers the physical address of the SVSM Calling Area into boot_svsm_caa_pa. > > If we move *only* snp_vmpl to .data, it survives the wipe (e.g., snp_vmpl = 1). > But boot_svsm_caa_pa is still in .bss and gets wiped to 0. The fallback in > early_is_sevsnp_guest() is skipped (since snp_vmpl != 0), leaving > boot_svsm_caa_pa == 0. Shortly after, when extract_kernel() attempts to accept > memory, the guest crashes when it tries to use physical address 0 for the SVSM > CAA. > > == Proposed Solutions == > > I analyzed the AI's analyses above to the best of my ability, and I think > it is correct. But I do not have an SVSM environment to test it out. > > To safely resolve this, we have two options. I'd like to ask the maintainers > which approach is preferred: > > Option 1: Revert commit 68a501d7fd82 > > By reverting the commit and bringing back the RMPADJUST check, we avoid > reading uninitialized .bss memory to determine the VMPL level. This sidesteps > the .bss initialization order issue entirely. > > Option 2: Move early SEV variables to .data (Proposed by Gemini) > > We can explicitly move snp_vmpl, boot_svsm_caa_pa, and ghcb_version to .data. > > u8 snp_vmpl __section(".data") = 0; > u16 ghcb_version __section(".data") = 0; > u64 boot_svsm_caa_pa __section(".data") = 0; > > This protects them from the garbage-read during direct boot, and properly > preserves their initialized SVSM states across the .bss wipe at .Lrelocated, > intentionally bypassing the need for the accidental MSR fallback recovery. > > Does anyone have a preference between reverting the original commit > versus moving the affected global variables to .data? > Or please let me know if AI's alert is a false positive. > I am happy to submit a formal patch for whichever route is preferred. > > Thanks, > Changyuan Lyu