From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (NAM03-DM3-obe.outbound.protection.outlook.com [40.107.80.73]) by mx.groups.io with SMTP id smtpd.web11.523.1574462885096247172 for ; Fri, 22 Nov 2019 14:48:05 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=qmFW5mRI; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.80.73, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zy+SPfrfrilvxqscJioxi+i9PgKdlZK7c4ZYNTAybYIJvaJAkBw8Moa6u53TmCvzdh89X3rvjG4Wd5SqGjor9XDHVKiLQQOe1t2E/HH4JcLZblW8oCiL/YFyVMoKPaUa0AvtIQ6L1AmIldFVAYAVrB/uPOXUDgYHOEuT+muj7Wvckmq+uRoUUlLtPvl+Q9xv4m/dv2fFaVWLQqMHWvl9cHNk/b5naJZ5rjpcXUvpgXXtlq1i+wJX/+gASaTEFkdXTWOjc3nht2GKUW7w3A300oJOYxpQJCpRwqiUApjl5DMRqkx9vW5/BSWF0sCfIMK7Z3iRJha7Z8mlquqintb+ww== 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=SZxZnZgAL3R1ZPm9d7qgyMsWWXx9BfJrbLYs5SLLmzM=; b=hzReg3XgLC5/XaKCFIxL4EpCCKzvrv1zMhw8EVA8yI//+X0mCWizUkj6ELGDFeXUwDZFvhsNGN7hDjGMzezvoV/+rJebcM5h42U4Q8twSa/ZYJwrSFuzy0bpdWMW8KTfrgPWnUmxTdqmRa0u2JlHT6/zTvEe46p4+Grm9uWnKDtTXCjFGI2CkYb+7hFbTJTh+Ru4FvOGFS0AYpHC17w1tBliK6aWWKyLlMSssgguJ0dJsnpn4hemN9R3duRaZ5ZZAnBlMM7igJGeKNfnDzp+Hd36fMat99oHA6DNefiCqf2EOfL11YDUBUNA32Dv7GQFEWa7amOkkNcIKdfGWdhwOQ== 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=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SZxZnZgAL3R1ZPm9d7qgyMsWWXx9BfJrbLYs5SLLmzM=; b=qmFW5mRIjwGPfobYysGipQIfmwSRzpNAkSt1CsOdAEzs4KkWrYjP9W++gGFNnOapwdYQwHqdT5z47i95WFUsJWGnuCifzkREFUEr7q7msqU+0VmUznO5QVgOLnGmwYbM/fme2Eki2D8Ko67ibun0jeWIBFHW21VpFhrKIFoaj4I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Received: from DM6PR12MB3163.namprd12.prod.outlook.com (20.179.71.154) by DM6PR12MB2987.namprd12.prod.outlook.com (20.178.198.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Fri, 22 Nov 2019 22:48:03 +0000 Received: from DM6PR12MB3163.namprd12.prod.outlook.com ([fe80::dd0c:8e53:4913:8ef4]) by DM6PR12MB3163.namprd12.prod.outlook.com ([fe80::dd0c:8e53:4913:8ef4%5]) with mapi id 15.20.2474.019; Fri, 22 Nov 2019 22:48:03 +0000 Subject: Re: [edk2-devel] [RFC PATCH v3 30/43] OvmfPkg/Sec: Add #VC exception handling for Sec phase To: Laszlo Ersek , devel@edk2.groups.io CC: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , Brijesh Singh References: <041cb6f6352c9e0f9982d316cd842c2daf57e7fa.1574280425.git.thomas.lendacky@amd.com> <12e35ff5-ff14-87d4-f4ac-604448289688@redhat.com> <268877ff-8593-845c-e6e6-fe763557c623@redhat.com> From: "Lendacky, Thomas" Message-ID: <12d86111-b972-db0a-ba91-ce05782986e2@amd.com> Date: Fri, 22 Nov 2019 16:48:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 In-Reply-To: <268877ff-8593-845c-e6e6-fe763557c623@redhat.com> X-ClientProxiedBy: SN4PR0401CA0041.namprd04.prod.outlook.com (2603:10b6:803:2a::27) To DM6PR12MB3163.namprd12.prod.outlook.com (2603:10b6:5:15e::26) Return-Path: thomas.lendacky@amd.com MIME-Version: 1.0 X-Originating-IP: [165.204.84.11] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1d5fb669-b600-409d-6465-08d76f9e0883 X-MS-TrafficTypeDiagnostic: DM6PR12MB2987:|DM6PR12MB2987: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02296943FF X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(199004)(52314003)(189003)(3846002)(76176011)(2870700001)(66066001)(229853002)(7736002)(26005)(86362001)(23746002)(386003)(6506007)(6116002)(6512007)(65806001)(305945005)(65956001)(66556008)(47776003)(2906002)(66946007)(53546011)(8676002)(8936002)(446003)(2616005)(66476007)(81156014)(6436002)(11346002)(36756003)(6486002)(19627235002)(81166006)(50466002)(14454004)(31686004)(14444005)(6246003)(58126008)(4326008)(31696002)(316002)(54906003)(52116002)(99286004)(186003)(5660300002)(478600001)(25786009);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR12MB2987;H:DM6PR12MB3163.namprd12.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JAWq5xM6GMRsIGnOs/XOXx5r+MmsS8N3qi+fPJbYj0BeyUCVcFGXKPxZeqUiJogD7BVjje60msJ5mgDac3WTowrViH+XRVWQysx+JzpvWJOiBj7PUsTZwjGwewGR3m+yx6LKoCrZW6+xP8IlBCEDIn0MOgK26swihvEFk/2db73KsEJYnINGFFAEi+lSoU8WOA2zUQflE52ZmRcdq6uVcZu6ro0ZOT55S1aOAQT3xeRClThlQgVFvhMYwF4eSwVmJyRB5Bwe6g1RUTE8naSuROA7FNrnHWOjXAr1B7wODkErYUp7iDYhASPpjUM/HG3SkK9onMfQf6JWI9BXVxcLfyWGMPwYgJvDfuhaO7e52dNsir781yqEjDudvu4zTzbfGVgQVlrKT8ff70M6F/MamcUw85vBKu7Dmtw6b9ImTKwM1zqHGLcVbtGzH6FhXs5E X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d5fb669-b600-409d-6465-08d76f9e0883 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2019 22:48:03.6747 (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: b4QEq3yIYwI5GnrxKINXGnOB0KZf1FVlxb+zKBFpyD2x+lMJtN2Zr+zQZHb4dCArrRF8ICUR14CG8oNVolHFPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2987 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/22/19 3:10 PM, Laszlo Ersek wrote: > On 11/22/19 17:30, Tom Lendacky wrote: >> On 11/22/19 6:52 AM, Laszlo Ersek wrote: >>> On 11/21/19 21:46, Tom Lendacky wrote: >>>> On 11/21/19 6:06 AM, Laszlo Ersek wrote: >>>>> On 11/20/19 21:06, Lendacky, Thomas wrote: >=20 >>>>>> @@ -737,6 +738,21 @@ SecCoreStartupWithStack ( >>>>>> =A0=A0=A0=A0=A0 Table[Index] =3D 0; >>>>>> =A0=A0=A0 } >>>>>> >>>>>> +=A0 // >>>>>> +=A0 // Initialize IDT >>>>>> +=A0 // >>>>>> +=A0 IdtTableInStack.PeiService =3D NULL; >>>>>> +=A0 for (Index =3D 0; Index < SEC_IDT_ENTRY_COUNT; Index ++) { >>>>>> +=A0=A0=A0 CopyMem (&IdtTableInStack.IdtTable[Index], &mIdtEntryTemp= late, >>>>>> sizeof (mIdtEntryTemplate)); >>>>>> +=A0 } >>>>>> + >>>>>> +=A0 IdtDescriptor.Base=A0 =3D (UINTN)&IdtTableInStack.IdtTable; >>>>>> +=A0 IdtDescriptor.Limit =3D (UINT16)(sizeof (IdtTableInStack.IdtTab= le) >>>>>> - 1); >>>>>> + >>>>>> +=A0 AsmWriteIdtr (&IdtDescriptor); >>>>>> + >>>>>> +=A0 InitializeCpuExceptionHandlers (NULL); >>>>>> + >>>>>> =A0=A0=A0 ProcessLibraryConstructorList (NULL, NULL); >>>>>> >>>>>> =A0=A0=A0 DEBUG ((EFI_D_INFO, >>>>> >>>>> (1) The problem here is that we call multiple library APIs before >>>>> calling ProcessLibraryConstructorList() -- namely CopyMem(), >>>>> AsmWriteIdtr(), and InitializeCpuExceptionHandlers(). >> >> We can reduce this exposure a bit and replace the CopyMem() call with >> something similar to the loop above it. >=20 > That would be nice, if you're not too annoyed by the extra busywork. >=20 >> I could also use assembler code directly in here to load the IDTR. >=20 > I think it would be enough to copy >=20 > MdePkg/Library/BaseLib/Ia32/WriteIdtr.nasm > MdePkg/Library/BaseLib/X64/WriteIdtr.nasm >=20 > under OvmfPkg/Sec, and use a new function name. >=20 >> That would leave just InitializeCpuExceptionHandlers(). Is there >> something that can added so as to warn when a library has a >> CONSTRUCTOR added to/part of the definition? >=20 > Nothing comes to my mind :( >=20 > [...] >=20 >>> (1) Append a UINT8 ("BOOLEAN") field to the SEV_ES_AP_JMP_FAR structure >>> (and possibly rename the structure), >>> >>> (2) in the OvmfPkgX64 reset vector, where you determine SEV-ES anyway, >>> explicitly set this field to zero if SEV-ES is disabled, and set it to >>> one, if SEV-ES is enabled, >>> >>> (3) In OvmfPkg/Sec, introduce a new (local) header file declaring the >>> function SevEsIsEnabled(), >>> >>> (4) Provide two C-language implementations (under the Ia32 and X64 >>> directories): in the 32-bit version, return constant FALSE; in the >>> 64-bit version, return the value of the new field. Something like: >>> >>> =A0=A0 return ((SEV_ES_AP_JMP_FAR *)FixedPcdGet32 >>> (PcdSevEsResetRipBase))->SevEsEnabled; >>> >>> FixedPcdGet32() is explicitly safe to use without library constructors >>> having run. >>> >>> Does this look viable? (It might require you to reshuffle patch 37 vs. >>> patch 30.) >> >> I think this does. Since this is SEC and the reset vector page isn't >> needed until PEI and later we could even just use the first byte (make a >> union with an SEC usage field) and make this even simpler. Then we don't >> have to worry about positioning it. >=20 > Ah, nice. I haven't done the WriteIdtr() stuff, yet, but the passing of the SEV-ES status from the ResetVector code to the SEC code via the SEV-ES page at 0x0080_B000 is working nicely. Thanks, Tom >=20 >> Let me work on that and see where I >> get. Anything after the #VC is established would use the current method >> of determine SEV-ES status. >=20 > Thanks! > Laszlo >=20