From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (NAM11-CO1-obe.outbound.protection.outlook.com [40.107.220.65]) by mx.groups.io with SMTP id smtpd.web08.5632.1627482859212137107 for ; Wed, 28 Jul 2021 07:34:19 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amd.com header.s=selector1 header.b=Np8zA9ff; 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.220.65, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=isrHHcENsN4V9HfgyFAjrCYukqmp+2pA5xIV1AIJLLWXI1FYGlMTb/3kc/xfblI3gIcgg40Yw+AeX0m1SbGlqHzjEwX1LW3nynn35p1OyHAbJu/jpO7I3plaC/4hJItsPwIIgf3yJsO0KrluiI00QIsIh+vRf99Ox7wTBAiWRyfJnhXE4nTVu+xMJpcSek4Goa4pQQtMWy1LVBSQip5u/3Ajo4g6+kJP5ip0Ec7BEM2KeIeWCGtyR+gPQViteqSmt+ljH3V8EWbyxtPbQmKY5jHHFEPEt09rnKPC2K1xOcepRnOM2aA2LsWGNYJfXHC+bc6nUt3nPEB2Zn5KqG1iwQ== 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=yMkj/vBQW4VcGSa9CsJuGHfCFslH9Q75tMHdUAKh0Yg=; b=BkMBA3jvjmuzsCptPZakyes7N3AabSb9qYAoh9tz4U4RUK0CvJAEYCyLgSiHP+bomn85/z3BezRZ/zTFn++0n2BrBrfvmAQfGXSP1QdZslpLNqWicI9RYKkboF3rL6PM+DWUzNgBGUJqGC5/x3H8Sc1B8UdR9NBw48iC8x5m8rIevRTcVz38fEntIOv8y/QtK28NjFWnrvbDN4R9qfS2D44sfvd510kg/p14dd2EAEBnXziZm3Yk+U/K20Zimfkc3eAORqz7wPchupaUp9G447c5P8RINBdaamDU/JJezbqet+sSrCNI6Ip5dcdPtp7w+UEQV+3tSgGh1u/i9BxzUQ== 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=yMkj/vBQW4VcGSa9CsJuGHfCFslH9Q75tMHdUAKh0Yg=; b=Np8zA9ffMG6rRXQXQAx43XdNiXX5ftR4bxIIlgzQ71FZBlPAWRFq5oUNndkjq5cLNROJWWRmAnp0DzuX7hqkpZ5jYX1WlAzhbgdsTPoroDFTSkXyat9qJdy3qi+9jUqtp/0jYeztKCjvx7vwYFuBePBu6//pAHBe9clP+sbvq6U= 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 SA0PR12MB4590.namprd12.prod.outlook.com (2603:10b6:806:93::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.28; Wed, 28 Jul 2021 14:34:17 +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.019; Wed, 28 Jul 2021 14:34:17 +0000 CC: brijesh.singh@amd.com, "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector To: "Yao, Jiewen" , "Xu, Min M" References: <4E4F0C83-ED04-4CFC-BDE2-33825C106DB9@intel.com> From: "Brijesh Singh" Message-ID: Date: Wed, 28 Jul 2021 09:34:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: X-ClientProxiedBy: SN4PR0801CA0015.namprd08.prod.outlook.com (2603:10b6:803:29::25) 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 [10.236.31.95] (165.204.77.1) by SN4PR0801CA0015.namprd08.prod.outlook.com (2603:10b6:803:29::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Wed, 28 Jul 2021 14:34:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 470c8b93-2ab6-4a6b-982c-08d951d4c763 X-MS-TrafficTypeDiagnostic: SA0PR12MB4590: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3FOhPzxUOUslDublAN2Ol7o8qJvMXfWJg5fyCbUk48oTnkm3rQEDtwW+IEcLAPicxwma/ppNLuoazmLub9OcIhbIK/EnK3kk6+9akKqqGoH5EJsWtP1EgyJF64j0I2gdm+9m0of10ud8b0+VHoZmv9eJHz+2xyusMLagw8FSB3NZ450PVU+hto2fYz58AkmD1H/6oE7GBtdnz8RNxF59MVo7qEAEjXrnelKEdiHvqLMk/Ot9ZTwyxo1MLqye2e3w1xWHgoXTk1A38isiPvaDw1zQg4EDTvfhoWtkuGMMi1vSiaDElYb1AggZ+2NO1l728Er9nkkBUvSv0SGqoEBqFgBbho8vrXsyxBnQX4ICjVdn8LRwF1gRatU3u/u6YY8fM1lxSCz8k2+VB6H+ltIGPiWvyZHg47CM0/34ds6mDggQf/MheG9yoPPwFUSsP8qgUq65+8H+TjPTCigypvWdgsxsLhBpOxNxZymSswJk8MW0H5wb0xKo/lcwRF9bPPRUpT0CNRC3+Xw0ajASh3zbXTxwXl8s7Xlxfu1lg1AaRJl6/FrTaD5QnYGUZS6MSdctQp8H3Inrj87CHzVsRkmIAXuB9vDBudoQ+9qeqzBmUr2T7sVDb9B2722V6Lgp0EVC+eh6hvP/h0RbpvmqJXNRYjMQp9PIv+520kQYC6IkFblngDGJ1iTAcjgb4ZwmM349RY5vOSu2w7Bjh6XlCRRkWXKF5oU8MjHu6LUtsiMJmqCSpXMBmNZRZ781c89eYGuxsC7pjdXbP8TxR4t+hrRlNg== 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)(136003)(366004)(346002)(396003)(376002)(39850400004)(44832011)(26005)(31696002)(53546011)(316002)(956004)(4326008)(8936002)(36756003)(5660300002)(38100700002)(8676002)(66556008)(83380400001)(38350700002)(31686004)(6486002)(110136005)(186003)(52116002)(2616005)(478600001)(66946007)(86362001)(16576012)(2906002)(66476007)(54906003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?X2G9aQ3sBupa/iVsMwAf+PaBJ+RBogVQl4R5ImP/BuyH9/iv4QNjXTthSy2+?= =?us-ascii?Q?bdKjPEPag3UmSVHDu7b62kTkyIJbcOd8zTu+M1C2Kp9hAVUMojnFV/eYE5eN?= =?us-ascii?Q?DoiQQEkN9kfjIwkoFV4LxrlZ5q5Pu5S3UBi6ZVuu/UeuIJoSjXxe6XLp5PIh?= =?us-ascii?Q?RxqL0QBJ9LOpRf8skgS6M6M1CT+jGUyXeB12t5IpHbfBYDRSebDgO5XPzXNu?= =?us-ascii?Q?ena/2HPZLdlZiC/2TQjdXnxLL4IcfI+HojV+zENo4qZ+wNbmdoYNnpg5kXFt?= =?us-ascii?Q?XjN9ZqCRs1bQpyWtyDJh6NgezmQLphoTEO7LIvKi/s1dCpVLOULFHNHSE/ml?= =?us-ascii?Q?tE+wgbMGDLW2by3mMDlVnW9TGDSWhoYqhLC1wvUj0ZcLOY17YCpcPHt7ghYJ?= =?us-ascii?Q?BgpDJVcl165sz8UrXPhqfP02AMcmDo3zd9glai6ps7A1Nbu2W2xSLBPP0xcl?= =?us-ascii?Q?hKTtmu8JEB5/DjkEoNRWkmzxVWt90X22ukbX3r0f1qU3QRhsPwcR1OjewsOW?= =?us-ascii?Q?JbM6gzxy3a6k+mlntY8mUalmIzGOB2YZE2dvG5N65e/byyjtxWQIeer3TpHO?= =?us-ascii?Q?8EAqkkat5FYKtOpAPlWyyf6mQfWLH7feD8KV+H2w9WV+Lsej821XZvD7mVW7?= =?us-ascii?Q?FaDiZcP7FuAXt5xgrpOrcmLpEgA+Cs5nQyWFctL+ZaTBMUvRg0wAHtIlzq7N?= =?us-ascii?Q?tWzZV11+PdZn0WIMOXofkPy5djpnnGy28SOepEMslTFWkHTJ4p7NIlP1YYhG?= =?us-ascii?Q?XP5VD2zXRRpxQSVHokcGvBFYpEPwmR8syW/EC6NlcP+r8rnXU24fL6PzUK0I?= =?us-ascii?Q?l9o1oD+eYG50bYGvgbaWx3HWaOItwBenGpuVCq8fAjwkUAO9mTXTF4Bmi3gz?= =?us-ascii?Q?qCP3paAhw3HRToL08AXqkupVJMR5jgEKxa19ApYJL07zm07xX77cMCKo3Ern?= =?us-ascii?Q?c78oo5+rStG9SZmNVOp52ZyIOYB82WYpiOACht+QVSBgU2ssWoOxz4tXNitj?= =?us-ascii?Q?s3wemdsfjjBE6lUg4jOiyzr1WXsqMz40xC5VvYfpvGlRci3O8RXK7z3L4Szt?= =?us-ascii?Q?pYMKf4FiKGzuzQo5iYWSpZdphaT0WlmhpHxypNwFxLJR/6BzxnblK91DR82C?= =?us-ascii?Q?EhJ9Oln0lMWqksae3gMC0zOtgArL6cP8kUYJMl8oXbxICC4bKLYvGOmmwh1f?= =?us-ascii?Q?cBPCHB7cq91h6aLiUpdA3Am2Pc4xn1d56UEer6jRB/kIPFPBzo1ORqnlhQc5?= =?us-ascii?Q?lWC/nkmhdmrL7OjbTPA6nSrfTMlR2jKZYKemZEM0SJV7s6OJsDauNXKkLa2d?= =?us-ascii?Q?yn/SqlhsJFtR2NtdS8tRjET+?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 470c8b93-2ab6-4a6b-982c-08d951d4c763 X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2021 14:34:17.1784 (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: mSEJYNk6M3OpKNDOqRtTcFGmbkXGe4o57msrOBvm80D5ElO9YbTPFRxQwjlGKiBLb0/i5gp+D9STY96D6MVLGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4590 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Jiewen and Min, See my comments below. On 7/28/21 2:54 AM, Yao, Jiewen wrote: > Yes. I am thinking the same thing. >=20 > [CC Flag memory location] > 1) A general purpose register, such as EBP. >=20 > 2) A global variable, such as > .data > TeeFlags: DD 0 >=20 > 3) A fixed region in stack, such as > dword[STACK_TOP - 4] >=20 > 4) A new CC common fixed region, such as > dword[CC_COMMON_FLAGS] >=20 > 5) A fixed region piggyback on existing CC working area, such as > dword[CC_WORKING_AREA] >=20 > Hi Brijesh/Min > Any preference? >=20 > [CC Indicator Flags] > Proposal: UINT8[4] >=20 > Byte [0] Version: 0 > byte [1] Length: 4 > byte [2] Type: > 0: legacy > 1: SEV > 2: TDX > byte [3] Sub Type: > If Type is 0 (legacy), then > 0: legacy > If Type is 1 (SEV), then > 0: SEV > 1: SEV-ES > 2: SEV-SNP > If Type is 2 (TDX), then > 0: TDX 1.0 >=20 > Thank you > Yao Jiewen >=20 >=20 >> -----Original Message----- >> From: Xu, Min M >> Sent: Wednesday, July 28, 2021 2:58 PM >> To: Yao, Jiewen >> Cc: Brijesh Singh ; devel@edk2.groups.io; Ard >> Biesheuvel ; Justen, Jordan L >> ; Erdem Aktas ; James >> Bottomley ; Tom Lendacky >> Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector >> >> On July 28, 2021 2:05 PM, Yao, Jiewen wrote: >>> It does not necessary to be a working area. >>> >>> We just need a common TEE flag to indicate if the system run in legacy,= SEV, >> or >>> TDX, right? >> Right. We need somewhere to store this flag, either in a Register or in = Memory. >> If it is memory, then in Tdx the memory region should be initialized by = host VMM. >>> >>> thank you! >>> Yao, Jiewen >>> >>> >>>> =E5=9C=A8 2021=E5=B9=B47=E6=9C=8828=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D= =881:07=EF=BC=8CXu, Min M =E5=86=99=E9=81=93=EF=BC=9A >>>> >>>> =EF=BB=BFOn July 27, 2021 8:46 PM, Yao, Jiewen wrote: >>>>> HI Min >>>>> I agree with Brijesh. >>>>> >>>>> The basic rule is: SEV file shall never refer to TDX data structure. >>>>> TDX file shall never refer to SEV data structure. >>>>> These code should be isolated clearly. >>>>> >>>>> Do we still need that logic if we follow the new pattern? >>>> I have replied to Brijesh's mail about the concern of the new pattern. >>>> >>>> I have some concern in the current pattern: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> OneTimeCall PreMainFunctionHookSev >>>> OneTimeCall PreMainFunctionHookTdx >>>> MainFunction: >>>> XXXXXX >>>> OneTimeCall PostMainFunctionHookSev >>>> OneTimeCall PostMainFunctionHookTdx >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> The TEE function need implement a TEE check function (such as IsSev, o= r >> IsTdx). >>>> >>>> Tdx call CPUID(0x21) to determine if it is tdx guest in the very >>>> beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV doe= s >>> the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to= 1. >>>> >>>> After that both TDX and SEV read the above WORK_AREA to check if it is= TDX >>> or SEV or legacy guest. >>>> >>>> In Tdx the access to SEV_ES_WORK_AREA will trigger error because >>> SEV_ES_WORK_AREA is *NOT* initialized by host VMM. >>>> In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error = too. >>>> >>>> I am wondering if TDX and SEV can use the same memory region (for >> example, >>> TEE_WORK_AREA) as the work area? >>>> So that this work area is guaranteed to be initialized in both TDX and >>>> SEV. Structure of the TEE_WORK_AREA may look like this: >>>> typedef struct { >>>> UINT8 Flag[4]; 'TDXG' or 'SEVG' or all-0 >>>> UINT8 Others[]; >>>> } TEE_WORK_AREA; >>>>> Are we reserving a new page for the TDX_WORK_AREA ? I am wondering why=20 can't we use the SEV_ES_WORK_AREA instead of wasting space in the MEMFD. The SEV_ES_WORK_AREA layout looks like this: typedef struct _SEC_SEV_ES_WORK_AREA { UINT8 SevEsEnabled; UINT8 Reserved1[7]; UINT64 RandomData; UINT64 EncryptionMask; } SEC_SEV_ES_WORK_AREA; There is reserved bit after the SevEsEnabled and one byte can be used=20 for the TdxEnabled; typedef struct _SEC_SEV_ES_WORK_AREA { UINT8 SevEsEnabled; UINT8 TdxEnabled; UINT8 Reserved2[6]; UINT64 RandomData; UINT64 EncryptionMask; } SEC_SEV_ES_WORK_AREA; The SEV_ES_WORK_AREA can be treated as a TEE_WORK_AREA and we can be=20 pull out from MemEncrypSevLib.h to CcWorkAreaLib.h and rename the=20 structure (if needed). Both the SEV-SNP and TEE host-VMM accepts the TEE_WORK_AREA before=20 booting the guest to ensure that its safe to access the memory without=20 going through the accept/validation process. In case of the TDX, the reset vector code sets the TdxEnabled on the=20 entry. In case of the SEV, the workarea is valid from SEC to PEI phase=20 only and it gets reused for other purposes. The PEI phase set the Pcd's (such as SevEsEnabled or SevEnabled etc) so that Dxe or other EDK2 core=20 does not need to know anything about the workarea and they simply can=20 read the PCDs. -Brijesh