From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (NAM10-DM6-obe.outbound.protection.outlook.com [40.107.93.51]) by mx.groups.io with SMTP id smtpd.web12.8852.1627562778791789918 for ; Thu, 29 Jul 2021 05:46:24 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amd.com header.s=selector1 header.b=rDmS9hIB; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.93.51, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i1qRdxTqDonX4zqpFM5Rk9zPeVH1hA0MOrsI+Uqc9fjooUjHNI1PD6RwDBL7ceof8jktox3JB1FZ73JAXSKI2Na6+HQuXq8rcjzUZcQghZO6n0/MhkP6LIjSIN5y05GXGvh/9OeSuMcyD6trXLAj+R62XJ9RJR8h8Kx238h8C1NLLirwfy6FUp4MT92cJxMA//Un1vgyDAbBGRz5tvglKb3cpHf7wLH3joLUAUSJ6qwM8R4G2RBlrp/X2Odu5KzYY07SVfr2aJRhT/Bj+HVEsHBim2zrFZYj28sYxIZ/WQ71pAWJhvA1uOmVmSNSDQ4qhx3+219hC03Nea92UP1gOg== 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-SenderADCheck; bh=+UP1pEv7vD4ZvLiKvkwqJdUWi9llpstV99vmdwthyEI=; b=eEtcSJPUKFDfXjEXIQa6eJdcIzGCDMVi4mzsct7SxcJNkJNvs0lW0Ssk0TkrTHkkS92kqRg3S02ZK5xxMCJ0DJOErWlKs7tEZ+JSFkEPplDtXwlN20A2R1GaLSbwYnszElHyTiVl9tcTwhzGmP0bWBNn2iyr6QsDsPfo86kJzk+IClmVLYzxIAlKGo6cN00LYwPqodx5ZaxtZDGRx+pWN6uUTe4o3yestJb4C/z+1Ni2QzJjkrsFyI9MJRbmQ4AFNH1+aOQi7YcH5K8oYXYbI/4Iclao9oLOE0ibaWPdQ31uL6gqfsY4nWrvtQofw9PFFkhb6XFvtAqZWCQlOFZ4LQ== 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=+UP1pEv7vD4ZvLiKvkwqJdUWi9llpstV99vmdwthyEI=; b=rDmS9hIB9y/YPpm7vQ9ZfIpnzDbxPO7Iaoo1+55AxFDF+LEW1iEpxya6+AIBrVwtok5EPhTrHZYV4mgTaztkWxN8SyrryqkYiVTNbgfj9KHmgOPZQCYUolET0PpwuVBFs+Zo/pKUJcBuhcCaCgUkP0J34MzFyinhBjm1fiu1FEc= Authentication-Results: amd.com; dkim=none (message not signed) header.d=none;amd.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SN6PR12MB4669.namprd12.prod.outlook.com (2603:10b6:805:7::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.29; Thu, 29 Jul 2021 12:46:14 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::a8a9:2aac:4fd1:88fa]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::a8a9:2aac:4fd1:88fa%3]) with mapi id 15.20.4373.021; Thu, 29 Jul 2021 12:46:14 +0000 Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector To: "Yao, Jiewen" , "Xu, Min M" , "devel@edk2.groups.io" CC: Ard Biesheuvel , "Justen, Jordan L" , Erdem Aktas , James Bottomley , Tom Lendacky References: <97ad36da-13cd-ccb1-48f3-17ee03934aa6@amd.com> <1e234d04-6348-5ac8-9c99-0557d6b44ef6@amd.com> <61da69ab-31fa-7179-53bf-0142badc5f9d@amd.com> From: "Brijesh Singh" Message-ID: <6104176a-866e-bd5b-8d84-7fb54595e03e@amd.com> Date: Thu, 29 Jul 2021 07:46:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: X-ClientProxiedBy: SN1PR12CA0063.namprd12.prod.outlook.com (2603:10b6:802:20::34) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by SN1PR12CA0063.namprd12.prod.outlook.com (2603:10b6:802:20::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.20 via Frontend Transport; Thu, 29 Jul 2021 12:46:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3f755d74-d8be-4723-7181-08d9528ed9b0 X-MS-TrafficTypeDiagnostic: SN6PR12MB4669: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iJXWz9Ay6pmQTv8QxdCD1EYuwGyJMcwEL/tkfR5mFwiA6lesbCDCwsxAW7rMLtxLZfWA8Wr0ESzHtB2mQhTm4CL9SYpoFAiCFJ1K2q1i4PSysAAHcjkJeMQMze4oathMLldtj/p0SV50m97ukyFGHAA86BkH0BpUyhuyc0rl61izSPAj1SFgLE6vwm5VRCVnEvxKNQBvZbJ2hypkwj52+nE5imy6LCOkjgOvxehUpHIGnBMezWObh3zu5qAh9q3nLDY2wlYBccI95UddIppAfTD4VX1p4eJwueanxTj9j8+r9EkyDJ/8ErxuXEcUbQz1Kmq2jUVE1nr13L0wYwHqeXaf+xYwBBAhCjmGsVa6PcCbyBW3ptrtjWKlSUJApk2l/WWvFXgTHGKgqYlJy+1X6dBjQEp6YcAA3fCXqNRxaiJucorJEOEKdTV1ZteRsFghNypbu+ayHTrEabXbeEOwDwkxVYmb51hNd1D5223MOFYqikUNm0jfYlE4E4HVMO9lFGnEk/aNSe/ira8dLdWKenggvv8hMqBhEnoIpOqipbU8zeWOaVAwhqJQ4xwLYrC69NLBSnsYQR/TvO63Ux8bDHdI6DijsgZxCkbYOAUgDxY2mB+ZCkIbG0G/Hv0XUBnsvMU3QIHw+ZJofEljA4cRddZQv5vRW0EfM+5JeSFvc7QM7U15tbTzWTHBbT1NtI1jgIXVZ13karKIDq5IZD9QFurP4HS/3nEfKgPmwrGu4uTiDXfx7pRG7Rq72irFSg7gTFz6Ix+S/eWNENG9aNxHdQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(346002)(376002)(39840400004)(396003)(136003)(110136005)(5660300002)(478600001)(956004)(31696002)(83380400001)(8676002)(19627235002)(4326008)(8936002)(2616005)(6486002)(6506007)(86362001)(66946007)(66556008)(316002)(186003)(53546011)(44832011)(6512007)(66476007)(36756003)(26005)(38100700002)(38350700002)(54906003)(52116002)(31686004)(2906002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?cwteYHsxGdXeSDqFx6eCQ4Vtd7Umzkga7I+oFo4vdu/iBxuLe3Q2JtdyF7Fk?= =?us-ascii?Q?fdyBnVbO2C8S8H69Z7kxFZ2mYhD4r/sVbhO+fs8tfQcm27vJ5AUVxVYM6xJH?= =?us-ascii?Q?VDfoegnRbOw+pBjsLVUuUdeamwOzFtVbtJWO0fQtWsR/rZm//YviAbC6ZX2e?= =?us-ascii?Q?FyUAI/QEr5y+2a89g/al4l1yWJBJFCcuShVFDK9MqGVrunWMpNyt8HNT7bQl?= =?us-ascii?Q?NKVip3k7xXQoipdTBhduijD0PGFEBCkBmXFOR62rnle1BB/y9CZt4CqhZl5K?= =?us-ascii?Q?mL0Ln86BhPs8hYW5L8OKsl5Fr1cJWhRh3DTPVjicbxApv66NP9hRTchr0KF4?= =?us-ascii?Q?8LZ/560JhUOyR5kHpoQ4pVAB9RxctazAmrMB5n8V+ohsBYhfGaZd4NivhkiD?= =?us-ascii?Q?7nI8F2V6I2JBdWWw0wLaWzYwZG9TS4zKElvy4ge0AsW98J2X0NOcyj/hqU40?= =?us-ascii?Q?AU+YwTkqRjdUkuyf+thvhaNVOhE6/rQRcGUuEV22a1g57fcsjSwkkRtYRVQe?= =?us-ascii?Q?22QHf4wDmvt0GhUwwvQoJxjlAg+wSTn4XUPZB77CyF+YmpHpJc8XdiQHxcf5?= =?us-ascii?Q?W+Hp/bUJZ53a6+lIGRjRP3mrbEeLATWKhr3rRAQ7UCckerDUV2WAM24MT4zB?= =?us-ascii?Q?SfUMwHnaA2sSU6XdO06me0EHZuvll5VJsYEReoCZzPV1HcxU515v0xDM9TT7?= =?us-ascii?Q?5HMazl4k5E3bv9muo1Brtq60k4seLNtH1rALMtsWSmybynuabeWiohj71ddj?= =?us-ascii?Q?u8PRmRaAHLoQmI6oLJ3c1Nob5yXEGS5FStbSs+n6HRO2YDAf2yNn2jOEOAPz?= =?us-ascii?Q?mljEoi0JKp4oi5fWWvTE/doNXIjtVOAR5No9vKgAMdGKMxPHPM9q/WcYtMoP?= =?us-ascii?Q?GA3veBcwlgzv8ET3b7Jcf4ETeHQneeY5b3AiwcjSvhaBGUv11FlzlYs2I4Pm?= =?us-ascii?Q?5b1k+IANsEj2UV9Hpg5qNhvjUpgi0CHD61C+kkE1fEaXz7Ptrp44li2BLnTY?= =?us-ascii?Q?6cXVdMGiKDmGdB0kJetmOPVmjrfP/v24kJ4zhWDvkpt0Zv+qeqPVzXbC1JDa?= =?us-ascii?Q?aHUoaJquK+RZzvNK2aK89J38mkcMqIGKS7ou/GIG3awoU+J+iCIN0LHlD6oB?= =?us-ascii?Q?kBKAdpTFxNlGt04brIDU7CGoFOlfzX93rMGQ+xrslbNymp3KEJpqL6UJRmeF?= =?us-ascii?Q?t12XmWsQIrikQ1xdWb6w1nKyKZzmDKH8xwstXMJeuH+6XOCv0zqd8jBYDiME?= =?us-ascii?Q?8ttIqJmBC5h9uIi45Gx/mN1Uw5ObAK4L5TBYa6BZ/zctkN/faxh+79F/D7p+?= =?us-ascii?Q?y7DBZSVDzOENiG6VEbkSy5Wt?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f755d74-d8be-4723-7181-08d9528ed9b0 X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2021 12:46:14.2357 (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: bP2dp+yHcYN7k0Vy4rTGgN7hP8ogl8QN+Bs3oeRr1J4yGR5xxn3XfOw2Kmk5FxsLkh+kWUB7eim0ncs5TAQfYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB4669 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 7/29/21 7:12 AM, Yao, Jiewen wrote: > Hey > I am not sure why Min did not response to my latest email. > I did give suggestion in my previous comment. > > =3D=3D=3D=3D=3D > CcWorkArea.Type =3D 0; > InitCcWorkAreaSev(); // set Type=3D1 if SEV > InitCcWorkAreaTdx(); // set Type=3D2 if TDX > =3D=3D=3D=3D=3D > > That is option 1. Yes that is exactly what we want Jiewen.=C2=A0 The OvmfPkg reset vector should initialize the type to zero on entry, and SEV/TDX will update the value (only if the feature is detected). > Thank you > Yao Jiewen > >> -----Original Message----- >> From: Xu, Min M >> Sent: Thursday, July 29, 2021 7:54 PM >> To: Brijesh Singh ; Yao, Jiewen >> ; devel@edk2.groups.io >> Cc: Ard Biesheuvel ; Justen, Jordan L >> ; Erdem Aktas ; James >> Bottomley ; Tom Lendacky >> Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in >> ResetVector >> >> On July 29, 2021 6:08 PM, Brijesh Singh wrote: >>> On 7/29/21 1:07 AM, Xu, Min M wrote: >>>> On July 29, 2021 12:29 PM, Brijesh Singh wrote: >>>>> On 7/28/21 9:44 PM, Xu, Min M wrote: >>>>>> Jiewen & Singh >>>>>> >>>>>> From the discussion I am thinking we have below rules to follow to >>>>>> the design the structure of TEE_WORK_AREA: >>>>>> 1. Design should be flexible but not too complicated 2. Reuse the >>>>>> current SEV_ES_WORK_AREA (PcdSevEsWorkAreaBase) as >>> TEE_WORK_AREA 3. >>>>>> TEE_WORK_AREA should be initialized to all-0 at the beginning of >>>>>> ResetVecotr 4. Reduce the changes to exiting code if possible >>>>>> >>>>>> So I try to make below conclusions below: (Please review) 1. >>>>>> SEV_ES_WORK_AREA is used as the TEE_WORK_AREA by both TDX and >>> SEV, >>>>>> maybe in the future it can be used by other CC technologies. >>>>>> >>>>>> 2. In MEMFD, add below initial value. So that TEE_WORK_AREA is >>>>>> guaranteed to be cleared in legacy guest. In TDX this memory region >>>>>> is initialized to be all-0 by host VMM. In SEV the memory region is >>> cleared as well. >>>>>> 0x00B000|0x001000 >>>>>> >>> gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpa >>> ce >>>>> Guid.PcdSevEsWorkAreaSize >>>>>> DATA =3D { >>>>>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>>>>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>>>>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>>>>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >>>>>> } >>>>> Hmm, I thought the contents of the data pages are controlled by the h= ost >>> VMM. >>>>> If the backing pages are not zero filled then there is no guarantee >>>>> that memory will be zero.=C2=A0 To verify it: >>>>> >>>>> 1. I applied your above change in OvmfPkgX86.fdt. I modified the DATA >>>>> values from 0x00 -> 0xCC >>>>> >>>>> 2. Modified the SecMain.c to dump the SevEsWorkArea on entry >>>>> >>>>> And dump does not contain the 0xcc. >>>>> >>>>> And to confirm further,=C2=A0 I attached to the qemu with the GDB bef= ore >>>>> the booting the OVMF, and modified the SevEsWorkArea with some >>>>> garbage number=C2=A0 and this time the dump printed garbage value I p= ut >>> through the debugger. >>>>> In summary, the OVMF to zero the workarea memory on the entry and >>> we >>>>> cannot rely on the DATA=3D{0x00, 0x00...} to zero the CCWorkArea. >>>> So in legacy guest, CCWorkArea is cleared to all-0 without the >>> DATA=3D{0x00,0x00...}, right? >>> >>> Okay, maybe I was not able to communicate it correctly. >>> >>> The run I did is for the legacy guest. For the legacy guest, the conten= ts of the >>> CCWorkArea may *not* be always zero even when you use the DATA=3D{0x00, >>> 0x00...}. >>> >>> Currently, Qemu uses zero filled backing pages, so we will get a zero f= illed >>> CCWorkArea; but nothing says that a backing page *must* be zero. >>> Another VMM may choose to do things differently. In summary, the OVMF >>> reset vector code must zero=C2=A0 the CCWorkArea=C2=A0 before calling S= EV or TDX >>> probes. >>> >> Ah, I see. >> In current CheckSevFeatures, byte[SEV_ES_WORK_AREA] is cleared to0. >> Then its values is set based on the result of SEV probe. >> >> There is a bug here. CheckTdxFeatures does the similar work and it sets = the >> WORK_AREA to 2. If CheckSevFeatures is called after CheckTdxFeatures, th= en >> WORK_AREA is cleared and it is set to 0 because it is not SEV. The value= is >> override. >> >> I think there are 2 options: >> Option 1: >> Neither CheckTdxFeatures nor CheckSevFeatures should clear WORK_AREA. >> Instead >> It should be cleared to 0 outside and before these 2 calls. So in Main16= after >> TransitionFromReal16To32BitFlat WORK_AREA is cleared to 0. In Tdx guest = this >> WORK_AREA >> is initialized to 0 by host VMM. >> >> Option 2: >> Another option is to figure out a mechanism that only one CheckXXXFeatur= es is >> called. >> Since there are 2 entry point in Main.asm: Main16 and Main32. >> In Main16 CheckSevFeatures is called after TransitionFromReal16To32BitFl= at. >> (eax should >> be saved because it is used in SetCr3ForPageTables64) >> In Main32 CheckTdxFeatures is called after ReloadFlat32. >> >> What's your opinion?