From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (NAM04-BN3-obe.outbound.protection.outlook.com [40.107.68.71]) by mx.groups.io with SMTP id smtpd.web10.764.1574440222861704427 for ; Fri, 22 Nov 2019 08:30:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=IdoqgVfz; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.68.71, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e0vOA1fxr1JQfXg3k1oqK/ahM/AcMK3Jw205++iVsEy4F9mI0n+Z9Z+vbaPcyNpsDfCfdNLFaSNdQJAMEceIBMQ6/KbQIiCCLyiAjdHAwpCFS/lqLpXpYE6EP/HD+Y0VUVLMoll/HwdAT3cpCsiKETQJnykOf435IiK7J+JsWnT0c25WCXh3wPp5IuMGwwVdAczFu71yFUm4mQfaFA2xR2Gxg0KbpNDljVZAQxIA/LmCzU/1XLNDROvs4/b/eYDDqOsOcR2i7C4scbxSJqCgu6tBddZNcWT9rz62ebLsErcm/CPjZj90tTEbJMvjrpDV9dmAS+GOqfB+BHt+2ZGJAg== 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=HsANAeH9QHV65rxWZC5NxkHxuRYKvh8FnpNK18HJ0ds=; b=k+DW9oLlZVYu7D3lPtXMOPLFqJ1FEtLXgxc6B69AM1T7F4Mob+kdcioF8zSX5lhvaKTdRB5Zqd96Dkqhv/gIJQM+TBz0thf1EtJH+Nm8nGO3R2OAhADjQDnlUA1VKESZzwh3UsE/zWi+xLSkocwvNWLKPlcDcVlXhpIY5IguDxFm8158Ykb4wJM5QToK1vsG/H+AepN2zrKI8C5K3BcAN8eTBiJaWTiwH/HkRXd4EfOL2NCYQqdCs2bYkNdMHs+p+SQK1LbC4d7krwwrSFUx+XCsJGVLsVOmz9bSi94Zmab7Mjkshcg4O3B/bHFvb3xtEi6arcT/8D6EJz5mGamtUQ== 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=HsANAeH9QHV65rxWZC5NxkHxuRYKvh8FnpNK18HJ0ds=; b=IdoqgVfznUY4p3HYcn8vu0RLV208RMF8SA/u7SxNHEvauyqdRoBB6+gc+fwQkOr63P1lOH8pzIHuThq63lzPaHkxp5QQnXRsmrP97D98aV4hSqL1EOgo9ENJ7+mEA5dX3v72hkodwxiqsB/Ljdy1K/wKsYWFOBJ7EqFopGS6TzQ= 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 DM6PR12MB2634.namprd12.prod.outlook.com (20.176.116.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.18; Fri, 22 Nov 2019 16:30:21 +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 16:30:21 +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> From: "Lendacky, Thomas" Message-ID: Date: Fri, 22 Nov 2019 10:30:17 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 In-Reply-To: X-ClientProxiedBy: DM6PR03CA0009.namprd03.prod.outlook.com (2603:10b6:5:40::22) 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: 2267d6c4-27a0-468a-24ca-08d76f694470 X-MS-TrafficTypeDiagnostic: DM6PR12MB2634:|DM6PR12MB2634: X-MS-Exchange-PUrlCount: 1 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)(366004)(39860400002)(136003)(376002)(396003)(346002)(189003)(199004)(51914003)(52314003)(6666004)(14444005)(11346002)(446003)(966005)(3846002)(66066001)(25786009)(65956001)(65806001)(6116002)(47776003)(81156014)(81166006)(8676002)(14454004)(478600001)(86362001)(2616005)(31696002)(5660300002)(6506007)(6306002)(45080400002)(8936002)(386003)(229853002)(6512007)(26005)(305945005)(6486002)(6436002)(7736002)(53546011)(2906002)(186003)(230700001)(66946007)(66556008)(66476007)(6246003)(76176011)(52116002)(4326008)(23746002)(58126008)(54906003)(36756003)(316002)(99286004)(50466002)(31686004);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR12MB2634;H:DM6PR12MB3163.namprd12.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A: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: =?Windows-1252?Q?61RXz8ESgiN8cmC2NHCPc2jWaEC3RZlwwntLGej7lCmIKN23jel12lzY?= =?Windows-1252?Q?nXQUQYtyIrO/PAwKZgZsqsB9vrjX0UAxtlztP+PIPW9wQt8XSRfAHYfT?= =?Windows-1252?Q?1QktbG1UynInR3EkaZiyX65+TRaxVNmQon34SMkNZoSdG0Hr2jT+EG3H?= =?Windows-1252?Q?4uL/Mhjae54ZlCwXaAV3T8CyubxznQrFa6MdhPhf7idVRb1wQ+5Hc/FS?= =?Windows-1252?Q?vrRrcnKr6TqDXjyqsDrR2JwnW1O7NqwNsHmuR7ygjjVytJDK6fhwpzgD?= =?Windows-1252?Q?oKRhy7Oja2tofutQxWKq/bNnDhGI/Y09TMjdcNvqvSO/43jCGH0P+91B?= =?Windows-1252?Q?1XYPhkmg4yUCjtHUVMq5uhMBxY1NPP52zASWNjtdUqC7dmnivBV/OmOK?= =?Windows-1252?Q?3n1uAlJe1v574eQ3BIecqljxhDtFlIyamZplC6lLL6TJpZOKewKuwsyh?= =?Windows-1252?Q?6FhFXCV5GH18Eq9OGaY1Gsc9f1CuOBhqX+c3IlCDBJMvoT3TaG1uK9YG?= =?Windows-1252?Q?n6FN2joXsxt4kwQrDD+0SiK7kOfrxKUamodUeiga3N7JQGJHiUUYg2+9?= =?Windows-1252?Q?6/cvBICV3w2OX5b8or6LzXkCZMh+wS6GPZSdRzXsW8f5UHBnk0XYQWBQ?= =?Windows-1252?Q?X6gVmpYfRu0v61jYzEUmH5gZNVpHrWjXpNS0mc8zQT/fqQqE4PRTnbR6?= =?Windows-1252?Q?aaVgD7uxDTPOgrOZ6m5xt0sqvy82g1t6GtUIUHCLGgq+ZoTBuFwRLfW1?= =?Windows-1252?Q?a5FaYLj+R6j2SxJu1rPHE20EEFZtH9SP2/WjEc/R9fW0J2+9PTCdmxj4?= =?Windows-1252?Q?O0PJflQpiKZO9ZV/vxhJiXZ0qrkSpF/vN6xZd5MujPE+8VOGqSfhrTZz?= =?Windows-1252?Q?B4Mb/b7wnx2spLdCqPYLdNR8zww1QAEZCG2lu8E8Z0V8+Z46M7lH8GY5?= =?Windows-1252?Q?EY1hWXJUF/6/BFeTnUEbaLvWR/Q9Fkl6wENkrIwITF9DMxzHdD7dYwZ3?= =?Windows-1252?Q?2kXD2ip5ZsLsiD/uWxyDz2NhjvkWb7BS6lL04k4DrHaG7qG3T1DNViqz?= =?Windows-1252?Q?5H4V9F1hbxT0qjMyMoBOVq/1wb8+3tMb5hzK6kgGQLiuosa2Pssbvt5P?= =?Windows-1252?Q?UT13GsYvsOeaYbK9X3y9eaqGDN5xzHhthjt2LsjwqaKqUokCrmVJl5Na?= =?Windows-1252?Q?cD+E2d8oir40RBKFTxMQvEQzFw452mYZY3vhMSGH8Xunk+taieiGYpnG?= =?Windows-1252?Q?Ixisb9cptBt/Y8Ip3bhFXo9d8tI07Jf/6Hq5dZ/4LZa2C/7c+MW3nUxJ?= =?Windows-1252?Q?4fd9m3FAMxmTG+0B/K64carW7jObo00+wCUBC7f89bBZgmnb3/r/5LnB?= =?Windows-1252?Q?kq3b1Ed/w6fTTgItf6zciRQD9WKBuZWjFXehVqhpjt4esWWz6n+15QIz?= =?Windows-1252?Q?W9SSA3ocVYHyJSuu/JL0GkQXKYxajQ5yFBGo1mMe2w/Er6tkvQoyK7G3?= =?Windows-1252?Q?WL2O76qGFTn7wKOckuDe0PxxcKI8kwmlq2dM3mRnFkz2kzwxRu5k8ToD?= =?Windows-1252?Q?ZepuoYYHO05X+Ge7Zw4qd0+1BjQKmn+tdny4G7HL3BS3Q8yKa6nYRNxh?= =?Windows-1252?Q?DrI7qdjW7vb0i9BGaztFLJyo+RQlyUZJ5yupfmerAi4nGFjyOxa/t+W+?= =?Windows-1252?Q?iTUXXtzE3W7nsPoiDX9xIM3FeomsW4xtxxJ3xi7314is9slx/l29wqtA?= =?Windows-1252?Q?Pl8QpHy7mGtjqBhImJPkJHHdbdgjlHajthObW86j6dbIpeMRVgBZqxL8?= =?Windows-1252?Q?xrHmS+VsURHllPtv3ZdkP+CM22fBQFllH7n/UDQ+a6qrBTMQOuNprGQx?= =?Windows-1252?Q?A8v9B9bqd+MwYQuPVhJlJ7K38nXn7XjTVeSEjtLssEnjkwFkwsE56EjV?= =?Windows-1252?Q?efhs6vn7iC/pCcdtkd9Yvzcy/LXFNYjblE8b+rq8o/qsh7Rg3Zw1dcUb?= =?Windows-1252?Q?vwyl7eeLq/MmuEoS72Z5D/RqUsHTPA4+qY//SwVXrr5vWydfMQpOkfU9?= =?Windows-1252?Q?uBJfqblk4TAOiE2iwDmmileSPmHSS6SSVXGeJRRsa/Pmvuz0Lexv0Jo0?= =?Windows-1252?Q?f1E=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2267d6c4-27a0-468a-24ca-08d76f694470 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2019 16:30:21.0651 (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: rj62kmJZwxPZ1uhGhCZGTRf4wWkR/PktKhANgp01e9E1ZHFGSKvfZ50+30sntfKaR5BCJ6gRKYvAy//7EcElHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2634 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: >>>> BZ: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198&data=02%7C01%7Cthomas.lendacky%40amd.com%7C86943210aff44681d5b908d76f4acf49%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637100239406633853&sdata=8APpMBall%2F2urZh6V3kpuWpsBjOh8GVqhWGNBjL%2B30U%3D&reserved=0 >>>> >>>> An SEV-ES guest will generate a #VC exception when it encounters a >>>> non-automatic exit (NAE) event. It is expected that the #VC exception >>>> handler will communicate with the hypervisor using the GHCB to handle >>>> the NAE event. >>>> >>>> NAE events can occur during the Sec phase, so initialize exception >>>> handling early in the OVMF Sec support. >>>> >>>> Cc: Jordan Justen >>>> Cc: Laszlo Ersek >>>> Cc: Ard Biesheuvel >>>> Signed-off-by: Tom Lendacky >>>> --- >>>> OvmfPkg/Sec/SecMain.inf | 1 + >>>> OvmfPkg/Sec/SecMain.c | 29 ++++++++++++++++------------- >>>> 2 files changed, 17 insertions(+), 13 deletions(-) >>>> >>>> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf >>>> index 63ba4cb555fb..7f53845f5436 100644 >>>> --- a/OvmfPkg/Sec/SecMain.inf >>>> +++ b/OvmfPkg/Sec/SecMain.inf >>>> @@ -50,6 +50,7 @@ [LibraryClasses] >>>> PeCoffExtraActionLib >>>> ExtractGuidedSectionLib >>>> LocalApicLib >>>> + CpuExceptionHandlerLib >>>> >>>> [Ppis] >>>> gEfiTemporaryRamSupportPpiGuid # PPI ALWAYS_PRODUCED >>>> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c >>>> index bae9764577f0..db319030ee58 100644 >>>> --- a/OvmfPkg/Sec/SecMain.c >>>> +++ b/OvmfPkg/Sec/SecMain.c >>>> @@ -24,6 +24,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> >>>> @@ -737,6 +738,21 @@ SecCoreStartupWithStack ( >>>> Table[Index] = 0; >>>> } >>>> >>>> + // >>>> + // Initialize IDT >>>> + // >>>> + IdtTableInStack.PeiService = NULL; >>>> + for (Index = 0; Index < SEC_IDT_ENTRY_COUNT; Index ++) { >>>> + CopyMem (&IdtTableInStack.IdtTable[Index], &mIdtEntryTemplate, sizeof (mIdtEntryTemplate)); >>>> + } >>>> + >>>> + IdtDescriptor.Base = (UINTN)&IdtTableInStack.IdtTable; >>>> + IdtDescriptor.Limit = (UINT16)(sizeof (IdtTableInStack.IdtTable) - 1); >>>> + >>>> + AsmWriteIdtr (&IdtDescriptor); >>>> + >>>> + InitializeCpuExceptionHandlers (NULL); >>>> + >>>> ProcessLibraryConstructorList (NULL, NULL); >>>> >>>> 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. I could also use assembler code directly in here to load the IDTR. 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? >>> >>> (See also the "SetMem" reference in the leading context, in the >>> source file -- it is not quoted in this patch.) >>> >>> Thus, would it be possible to move all the "+" lines, quoted above, >>> just below the ProcessLibraryConstructorList() call? >> >> Unfortunately, I can't. The invocation of >> ProcessLibraryConstructorList() results in #VC exceptions and so the >> exception handler needs to be in place before invoking >> ProcessLibraryConstructorList(). It looks like there are some >> SerialPort I/O writes to initialize the serial port and some PCI I/O >> reads and writes from AcpiTimerLibConstructor() in >> OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.c. > > I have to accept what you're saying, but this makes the code quite > brittle. It's a tenet that we don't call library APIs before the library > constructor had a chance to initialize whatever memory or hardware the > library APIs rely on. > > So, in this case, > > (a) please add a comment above this block that we're making an exception > with CopyMem(), AsmWriteIdtr() and InitializeCpuExceptionHandlers(), Can do. > > (b) I'd still like to see this pre-constructor logic restricted to > SEV-ES. (More on that below.) Yup, propagating the SEV-ES status from the ResetVector seems to be the way to go. > > So something like: > > if (SevEs) { > // > // We have to initialize the IDT and set up exception handlers here, > // i.e. before calling library constructors, because those library > // constructors may access hardware such that #VC exceptions are > // triggered. > // > // Due to this code executing before library constructors, *all* > // library API calls are theoretically interface contract > // violations. However, because we are in SEC (executing in flash), > // those constructors cannot write variables with static storage > // duration anyway. Furthermore, we call a small, restricted set of > // APIs, such as CopyMem(), AsmWriteIdtr(), > // InitializeCpuExceptionHandlers(), where we require that the > // underlying library instance not trigger any #VC exceptions. > // > InitIdt (); > InitExceptionHandlers (); > } > ProcessLibraryConstructorList (); > if (!SevEs) { > InitIdt (); > } > > This makes me feel safer because: > - we're explicit about the principles we (have to) break, > - even our limited assumptions are restricted to SEV-ES. > >> >>> >>> >>> (2) If possible I'd like to restrict the >>> InitializeCpuExceptionHandlers() call to SevEsIsEnabled(). >>> >>> (Unless you're implying that InitializeCpuExceptionHandlers() is >>> useful even without SEV-ES -- but then the commit message should be >>> reworded accordingly.) >> >> It does give you earlier exception handling and displays the exception >> information should an exception occur during SEC. >> >> But, it might require some tricks to somehow communicate from the >> ResetVector code to the SecMain code that SEV-ES is enabled. This is >> because you need to do a CPUID instruction to determine if SEV-ES is >> enabled, which will generate a #VC, which requires an exception >> handler... > > So even *checking* whether SEV-ES is enabled requires a #VC handler to > be set up. Thanks for the reminder. How about this idea: in > > [edk2-devel] [RFC PATCH v3 37/43] > OvmfPkg: Reserve a page in memory for the SEV-ES AP reset vector > > you are carving out a page at PcdSevEsResetRipBase -- only in > "OvmfPkgX64.fdf". And, a very small (leading) stretch of that page is > used as the SEV_ES_AP_JMP_FAR structure. > > Now, could we implement the following? > > (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: > > 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. 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. Thanks! Tom > > Thanks! > Laszlo > >> >> Thanks, >> Tom >> >>> >>> If you agree to that restriction, then I further suggest reordering this >>> patch against the next one: >>> >>> [edk2-devel] [RFC PATCH v3 31/43] >>> OvmfPkg/Sec: Enable cache early to speed up booting >>> >>> Namely, if you put that patch first, then in the present patch you can >>> extend the already existing SevEsIsEnabled()-dependent scope, with a >>> call to InitializeCpuExceptionHandlers(). >>> >>> The end result would be something like: >>> >>> ProcessLibraryConstructorList(); >>> >>> // >>> // Initialize IDT >>> // ... >>> // >>> >>> if (SevEsIsEnabled()) { >>> // >>> // non-automatic exit events (NAE) can occur during SEC ... >>> // >>> InitializeCpuExceptionHandlers (NULL); >>> >>> // >>> // Under SEV-ES, the hypervisor can't modify CR0 ... >>> // >>> AsmEnableCache (); >>> } >>> >>> What's your opinion? >>> >>> Thanks! >>> Laszlo >>> >>>> @@ -751,19 +767,6 @@ SecCoreStartupWithStack ( >>>> // >>>> InitializeFloatingPointUnits (); >>>> >>>> - // >>>> - // Initialize IDT >>>> - // >>>> - IdtTableInStack.PeiService = NULL; >>>> - for (Index = 0; Index < SEC_IDT_ENTRY_COUNT; Index ++) { >>>> - CopyMem (&IdtTableInStack.IdtTable[Index], &mIdtEntryTemplate, sizeof (mIdtEntryTemplate)); >>>> - } >>>> - >>>> - IdtDescriptor.Base = (UINTN)&IdtTableInStack.IdtTable; >>>> - IdtDescriptor.Limit = (UINT16)(sizeof (IdtTableInStack.IdtTable) - 1); >>>> - >>>> - AsmWriteIdtr (&IdtDescriptor); >>>> - >>>> #if defined (MDE_CPU_X64) >>>> // >>>> // ASSERT that the Page Tables were set by the reset vector code to >>>> >>> >> >