CN115668157A

CN115668157A - 计算设备的安全引导

Info

Publication number: CN115668157A
Application number: CN202080101860.8A
Authority: CN
Inventors: 冯康宁; 黄哲逸; C-H·赵
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2020-06-08
Filing date: 2020-06-08
Publication date: 2023-01-31
Also published as: US20230334156A1; DE112020007303T5; WO2021251950A1; TW202147157A; TWI779515B

Abstract

描述了用于统一可扩展固件接口（UEFI）兼容设备的安全引导的技术。在一示例中，可以在计算设备的引导期间检测与计算设备的硬件组件相关联的驱动程序的执行。基于该检测，可以计算UEFI的系统表的第一驱动程序散列，其中系统表是存储计算设备的配置细节以及UEFI服务的数据结构。此后，可以基于检测到驱动程序的执行的完成来计算系统表的第二驱动程序散列。然后，可以比较第一驱动程序散列和第二驱动程序散列，以确定对UEFI的系统表的篡改。

Description

计算设备的安全引导

背景技术

计算设备包括需要在操作之前进行配置的多个硬件组件。诸如统一可扩展固件接口（UEFI）之类的现代系统固件允许在计算设备引导期间执行与这样的硬件组件相关联的驱动程序。驱动程序的这样的执行促进硬件组件在计算设备引导期间被配置和初始化。

附图说明

参考附图提供了详细描述，在附图中：

图1图示了根据本主题的一示例的用于确定对统一可扩展固件接口（UEFI）的篡改的计算设备；

图2图示了根据本主题的另一个示例的用于确定对UEFI的篡改的计算设备；

图3图示了根据本主题的一示例的用于确定对UEFI的篡改的方法；

图4图示了根据本主题的一示例的用于UEFI兼容计算设备的安全引导的方法；以及

图5图示了根据本主题的一示例的实现用于确定对计算设备中的UEFI的篡改的非暂时性计算机可读介质的系统环境。

具体实施方式

一般而言，统一可扩展固件接口（UEFI）通过在执行之前验证与各种硬件组件相关联的驱动程序来确保计算设备的安全引导。驱动程序的验证是通过证实与驱动程序相关联的数字签名来施行的，其中数字签名在其开发期间与驱动程序链接，并且指示驱动程序的真实性。

与硬件组件相关联的驱动程序一般以二进制格式可用，而没有任何与之相关联的源代码，其中驱动程序的二进制格式通过附随驱动程序的数字签名可验证。因此，如果驱动程序的源代码被篡改，例如在驱动程序开发期间被恶意代码篡改，并且此后被数字地签名，则驱动程序的完整性可能无法查明。因此，驱动程序的恶意代码可能损害UEFI连同存储在计算设备上的用户数据的安全性。

根据本主题的示例实现方式，描述了用于UEFI兼容计算设备的安全引导的技术。

在操作中，在引导计算设备时，检测用于配置计算设备的硬件组件的驱动程序的执行。基于该检测，计算UEFI的系统表的第一散列，其中系统表是存储计算设备的配置细节以及各种UEFI服务的数据结构。然后，允许执行驱动程序用于配置硬件组件以进行操作。一旦硬件组件的配置完成，就计算系统表的第二散列并且将其与第一散列进行比较。然后，确定第一散列和第二散列是否相等。

如果第一散列和第二散列不相等，则可以确定系统表已经被篡改。因此，可以发出指示对系统表的篡改的通知。在这样的情形下，对系统表所做出的修改可以被回滚，并且驱动程序可以被阻止任何进一步的执行。因此，在计算设备的随后引导期间，驱动程序的执行可以被阻止，并且计算设备可以在不初始化与驱动程序相关联的硬件组件的情况下引导。

另一方面，如果发现第一散列和第二散列相等，则可以确定尚未对系统表做出修改。在这样的情形下，计算设备可以继续进行正常引导。

因此，上述技术通过检测由与计算设备的硬件组件相关联的驱动程序对UEFI的系统表所做出的任何修改来确保UEFI的系统表的内容的完整性。此外，阻止驱动程序的进一步执行避免了恶意代码在计算设备的随后引导期间的执行，从而确保了计算设备的安全引导。

参考图1至图5进一步描述了上面的技术。应当注意的是，描述和各图仅仅图示了本主题的原理连同本文中描述的示例，并且不应当被解释为对本主题的限制。因此，要理解的是，可以设计尽管在本文中没有明确描述或示出但是体现了本主题原理的各种布置。此外，本文中的记载了本主题的原理、方面和实现方式的所有陈述以及其具体示例意图涵盖其等同物。

图1图示了根据本主题的一示例的用于确定对统一可扩展固件接口（UEFI）的篡改的计算设备100。计算设备100的示例可以包括但不限于膝上型计算机、台式计算机、平板和智能电话。

计算设备100可以包括可以在计算设备100的预操作系统（OS）初始化期间初始化的多个硬件组件。另外，多个组件中的每一个可以对应地具有与之相关联的驱动程序，其中每个驱动程序可以对应于多个回调函数。

在说明性示例中，与计算设备100的第一硬件组件相关联的第一驱动程序可以用于将数据发布到高级配置和功率接口（ACPI）表中，其中，ACPI表在一示例中可以存储计算设备100的硬件配置信息和功率管理信息。在所述示例中，要发布到ACPI表中的数据在对与计算设备100的第二硬件组件相关联的第二驱动程序的执行之后变得可用。在这样的情形下，第一驱动程序可以注册回调函数来监测该数据的可用性。当该数据的可用性被确定为真时，可以触发一事件来调用第一驱动程序的回调函数。因此，可以执行第一驱动程序的回调函数，并且可以在ACPI表中发布该数据。

计算设备100可以包括检测引擎102，以确定与计算设备100的硬件组件相关联的驱动程序的回调函数的执行。在计算设备100的预OS初始化期间，可以在驱动程序执行环境（DXE）阶段中检测回调函数的执行。

基于检测到回调函数的执行，计算设备100的散列引擎104可以计算UEFI的系统表的第一回调函数散列，其中系统表是存储计算设备的配置细节以及各种UEFI服务的数据结构。

散列引擎104可以随后检测回调函数的执行的完成。基于该检测，散列引擎104可以计算驱动程序的第二回调函数散列。

然后，计算设备100的确定引擎106可以将第一回调函数散列与第二回调函数散列进行比较，以查明系统表是否已被篡改。因此，可以标识由于执行回调函数而对系统表做出的任何修改，从而确保存储在系统表中的内容的完整性。

图2图示了根据本主题的另一个示例的用于确定对UEFI的篡改的计算设备100。如较早所描述，计算设备100的示例可以包括但不限于台式计算机、膝上型计算机、智能电话和平板。

计算设备100可以包括处理器202和耦合到处理器202的存储器204。可以通过使用专用硬件以及能够执行指令的硬件来提供各图中所示出的各种元件的功能，包括被标记为“（一个或多个）处理器”的任何功能块。当由处理器提供时，这些功能可以由单个专用处理器、单个共享处理器、或多个个体处理器来提供，其中一些处理器可以是共享的。此外，术语“处理器”的明确使用将不应被解释为排他地指代能够执行指令的硬件，并且可以隐含地包括但不限于数字信号处理器（DSP）硬件、网络处理器、专用集成电路（ASIC）、现场可编程门阵列（FPGA）。标准和/或定制的其它硬件也可以耦合到处理器202。

存储器204可以包括任何计算机可读介质，包括例如易失性存储器（例如，随机存取存储器（RAM））和/或非易失性存储器（例如，ROM、EPROM、闪速存储器等）。

另外，计算设备100还可以包括（一个或多个）引擎206，引擎206可以包括检测引擎102、散列引擎104、确定引擎106和修改引擎208。

在一示例中，（一个或多个）引擎206可以被实现为硬件、固件及其组合。在本文中描述的示例中，硬件和固件的这样的组合可以以若干种不同的方式实现。例如，引擎的固件可以是存储在非暂时性机器可读存储介质上的处理器可执行指令，并且引擎的硬件可以包括处理资源（例如，实现为单个处理器或多个处理器的组合），以执行这样的指令。

根据本主题的实现方式，机器可读存储介质可以存储指令，当由处理资源执行时，所述指令实现引擎的功能。在这样的实现方式中，计算设备100可以包括用于存储指令的机器可读存储介质和执行指令的处理资源。

在本主题的一示例中，机器可读存储介质可以位于计算设备100内。然而，在其它示例中，机器可读存储介质可以位于不同的位置处，但是可由计算设备100和处理器202访问。

计算设备100可以进一步包括数据210，除其它事物之外，数据210尤其用作用于存储可以由（一个或多个）引擎206获取、处理、接收或生成的数据的储存库。数据210可以包括散列数据212、确定数据214和其它数据216。在一示例中，数据210可以存储在存储器204中。

在本主题的一示例实现方式中，具有UEFI的计算设备的预OS初始化被分成多个阶段，即安全性（SEC）阶段、预EFI（PEI）阶段、驱动程序执行环境（DXE）阶段、引导设备选择（BDS）阶段和瞬时系统加载（TSL）阶段。预OS初始化可以以SEC阶段开始，其中可以施行初始操作以确保在计算设备100被通电或重启之后用于初始化处理器、芯片组和主板的固件的完整性。然后，预OS初始化可以继续进行到PEI阶段，其中PEI阶段提供了加载和调用用于计算设备100的处理器、芯片组和主板的特定初始配置例程的标准化方法。PEI阶段的主要目的是确定计算设备100的引导路径，并且初始化和分配包含DXE基础和架构协议的最小量的RAM和永久存储器，以允许DXE阶段的实例化。

在DXE阶段中，施行计算设备100的各种硬件组件的初始化。各种硬件组件的初始化可以通过执行与各种硬件组件中的每一个相关联的不同驱动程序来促进。在一示例中，不同驱动程序的发现和执行由DXE调度程序（dispatcher）来促进。

在本主题的一示例中，DXE调度程序可以耦合到检测引擎102，其中检测引擎102在DXE阶段中检测与计算设备100的硬件组件相关联的驱动程序的执行。驱动程序可以是DXE驱动程序和UEFI驱动程序中的一个。

基于由检测引擎102对驱动程序执行的检测，散列引擎104可以生成系统管理中断（SMI），其中SMI的生成引起DXE阶段内系统管理模式（SMM）的触发。SMM的触发可以将处理器202的状态保存在被指定为系统管理RAM（SMRAM）的RAM的安全区域中。

另外，散列引擎104可以基于检测到驱动程序的执行来计算UEFI的系统表的第一驱动程序散列，并且可以将第一驱动程序散列存储在散列数据214中。如较早所解释，系统表是存储计算设备的配置细节以及各种UEFI服务的数据结构。

各种UEFI服务可以包括UEFI引导服务、UEFI运行时服务和协议服务。UEFI引导服务和UEFI运行时服务可以分别通过被包括在系统表中的UEFI引导服务表和UEFI运行时服务表来访问。另外，协议服务是一组相关的功能和数据字段，其可以用于针对诸如控制台、磁盘和网络之类的设备提供软件抽象。

在驱动程序的执行时，指向系统表的指针可以被传递到驱动程序。将指针传递到驱动程序允许驱动程序访问计算设备的配置信息连同各种UEFI服务，以初始化与其相关联的硬件组件。

将注意的是，一旦系统表的第一驱动程序散列被计算并存储在散列数据214中，SMM就可以被终止并且驱动程序被执行。

一旦驱动程序的执行完成，散列引擎104就可以重新生成SMI，从而在DXE阶段内重新触发SMM。随后，散列引擎104可以计算系统表的第二驱动程序散列，并且可以将其存储在散列数据214中。在一示例中，散列数据214可以被存储在SMRAM中，以防止在SMM之外访问第一驱动程序散列和第二驱动程序散列。

散列引擎104可以进一步耦合到确定引擎106，其中确定引擎106可以比较系统表的第一驱动程序散列和第二驱动程序散列，并且将比较的结果存储在确定数据214中。在一示例中，确定数据214也可以被存储在SMRAM中。

第一驱动程序散列和第二驱动程序散列可以被比较，以标识在驱动程序执行期间是否已经对系统表做出了任何修改。

如果确定引擎106确定第一驱动程序散列和第二驱动程序散列相等，则确定引擎106可以查明尚未对系统表做出修改。随后，可以确定DXE调度程序是否有更多的驱动程序要加载和执行。如果没有标识出其它驱动程序用于执行，则DXE阶段可以结束，并且控制可以传递到用于加载OS的随后阶段。

另一方面，如果确定引擎106确定第一驱动程序散列和第二驱动程序散列不相等，则确定引擎106可以确定驱动程序的执行已经篡改了UEFI的系统表。在这样的情形下，驱动程序可能被阻止。另外，在一示例中，驱动程序的执行可以在计算设备100的随后引导期间被阻止。

随后，修改引擎208可以撤销在驱动程序执行期间对系统表做出的任何修改。

一旦驱动程序的执行完成，DXE调度程序就可以进一步标识与计算设备的任何其它组件相关联的任何其它驱动程序是否需要执行。

在一示例中，DXE调度程序可以不标识与任何其它硬件组件相关联的任何其它驱动程序用于执行。在这样的情形下，可以标识耦合到计算设备的视频输出设备。随后，可以显示指示对系统表的篡改的通知连同驱动程序的细节，接着是重新引导计算设备。

在另一示例中，DXE调度程序可以发现并执行与计算设备100的另一硬件组件相关联的另一驱动程序的回调函数。在所述示例中，耦合到DXE调度程序的检测引擎102可以检测回调函数的执行。

基于该检测，散列引擎104可以引起SMM的触发。散列引擎104然后可以计算系统表的第一回调函数散列，并且将其存储在散列数据214中。随后，可以终止SMM，并且可以完成回调函数的执行。

一旦回调函数的执行完成，散列引擎104就可以重新触发SMM，并且可以计算系统表的第二回调函数散列。此后，第二回调函数散列可以被存储在散列数据214中。

确定引擎106可以比较第一回调函数散列和第二回调函数散列，以查明回调函数的执行是否已经篡改UEFI的系统表。

如果确定引擎106确定第一回调函数散列和第二回调函数相等，则确定引擎106可以确定尚未对UEFI的系统表做出修改。

另一方面，如果确定引擎106确定第一回调函数散列和第二回调函数散列不相等，则确定引擎106可以确定回调函数的执行已经篡改了系统表。因此，另一驱动程序可能被阻止。随后，修改引擎208可以撤销在回调函数执行期间对系统表所做出的修改。

DXE调度程序可以再次标识是否仍存在与任何其它硬件组件相关联的任何其它驱动程序用于执行。在一示例中，DXE调度程序可以不标识与任何其它硬件组件相关联的任何其它驱动程序用于执行。在这样的情形下，可以确定视频输出设备是否耦合到计算设备100。如果没有发现视频输出设备耦合到计算设备100，则可以通过使安装在计算设备100上的发光二极管（LED）闪烁来显示指示对UEFI的攻击的通知，接着是重新引导计算设备100。

图3图示了根据本主题的一示例的用于确定对计算设备中的UEFI的篡改的方法300。尽管方法300可以在各种系统中实现，但是为了便于解释，参考上述计算设备100来提供方法300的描述。描述方法300的次序不意图被解释为限制，并且任何数量的所描述的方法框可以以任何次序被组合以实现方法300或替代方法。

可以理解的是，方法300的框可以在计算设备100中施行。如将容易理解的，方法300的框可以基于存储在非暂时性计算机可读介质中的指令来执行。非暂时性计算机可读介质可以包括例如数字存储器、诸如磁盘和磁带之类的磁性存储介质、硬盘驱动器或光学可读数字数据存储介质。

在框302处，可以在具有统一可扩展固件接口（UEFI）的计算设备的引导期间检测与计算设备的硬件组件相关联的驱动程序的执行。驱动程序可以是驱动程序执行环境（DXE）驱动程序和UEFI驱动程序中的一个。在一示例中，驱动程序的执行可以由计算设备100的检测引擎102来检测。

在框304处，计算UEFI的系统表的第一驱动程序散列，其中系统表是存储计算设备的配置细节以及UEFI服务的数据结构。在一示例中，计算设备100的散列引擎104可以计算系统表的第一驱动程序散列。

在框306处，可以检测驱动程序执行的完成。在一示例中，检测引擎102可以检测驱动程序执行的完成。

在框308处，基于检测到驱动程序执行的完成，可以计算系统表的第二驱动程序散列。在一示例中，第二驱动散列可以由散列引擎104来计算。

在框310处，可以比较第一驱动程序散列和第二驱动程序散列，以确定对UEFI的系统表的篡改。在一示例中，确定引擎106可以确定对UEFI的系统表的篡改。如果确定UEFI的系统表已经被篡改，则可以标识耦合到计算设备100的视频输出设备，并且可以在该视频输出设备上显示提供驱动程序的细节的通知。否则，该方法可以继续进行到在计算设备上加载操作系统。

图4图示了根据本主题的一示例的用于UEFI兼容计算设备的安全引导的方法400。尽管方法400可以在各种系统中实现，但是为了便于解释，参考上述计算设备100来提供方法400的描述。描述方法400的次序不意图被解释为限制，并且任何数量的所描述的方法框可以以任何次序被组合以实现方法400或替代方法。

可以理解的是，方法400的框可以在计算设备100中施行。如将容易理解，方法400的框可以基于存储在非暂时性计算机可读介质中的指令来执行。非暂时性计算机可读介质可以包括例如数字存储器、诸如磁盘和磁带之类的磁性存储介质、硬盘驱动器或光学可读数字数据存储介质。

在框402处，可以在具有统一可扩展固件接口（UEFI）的计算设备的引导期间在驱动程序执行阶段（DXE）中检测与计算设备的硬件组件相关联的驱动程序的执行。驱动程序可以是驱动程序执行环境（DXE）驱动程序和UEFI驱动程序中的一个。基于检测到与硬件相关联的驱动程序，可以生成系统管理中断（SMI），从而在DXE阶段内触发系统管理模式（SMM）。SMM的触发可以将计算设备的处理器的状态保存在被指定为系统管理RAM（SMRAM）的RAM的安全区域中。在一示例中，驱动程序的执行可以由计算设备100的检测引擎102来检测。

在框404处，计算UEFI的系统表的第一驱动程序散列，其中系统表是存储计算设备的配置细节以及各种UEFI服务的数据结构。各种UEFI服务可以包括UEFI引导服务、UEFI运行时服务和协议服务。第一驱动程序散列可以被存储在RAM的安全区域中。随后，SMM可能被终止。在一示例中，UEFI的系统表的第一驱动程序散列可以由计算设备100的散列引擎104来计算。

在框406处，检测系统表的第二驱动程序散列的执行的完成。基于该检测，SMI被重新生成，从而重新触发SMM。此后，系统表的第二驱动程序散列被计算并存储在SMRAM中。在一示例中，第二驱动散列可以由散列引擎104来计算。

在框408处，可以从SMRAM获取系统表的第一驱动程序散列和第二驱动程序散列，并且将它们彼此进行比较。比较的结果然后可以被存储在SMRAM中，接着是终止SMM。在一示例中，计算设备100的确定引擎106可以比较第一驱动散列和第二驱动散列。

随后，在框410处，可以检测与计算设备的另一硬件组件相关联的另一驱动程序的回调函数的执行。在一示例中，回调函数的执行的检测可以由检测引擎102来检测。

在框412处，基于该检测，可以在DXE阶段内重新触发SMM模式。然后，可以计算系统表的第一回调函数散列，并且将其存储在SMRAM中，接着是终止SMM。然后可以执行回调函数。

在框414处，可以检测回调函数的执行的完成。基于该检测，可以重新触发SMM，并且可以计算第二回调函数散列。然后，第二回调函数可以被保存在SMRAM中。在一示例中，第二回调函数散列可以由散列引擎104来计算。

在框416处，可以将第一回调函数散列与第二回调函数散列进行比较。上述比较的结果然后可以被存储在SMRAM中。在一示例中，确定引擎106可以将第一回调函数散列与第二回调函数散列进行比较。

在框418处，基于第一和第二驱动程序散列以及第一和第二回调函数散列中的至少一个的比较的结果，可以查明是否已经存在对UEFI的系统表的篡改。在一示例中，确定引擎106可以确定对UEFI的系统表的篡改。

在一示例中，如果发现第一驱动程序散列和第二驱动程序散列不相等，则可以确定驱动程序的执行导致了对系统表的篡改。因此，驱动程序可能被阻止。在所述示例中，如果发现第一回调函数散列和第二回调函数散列不相等，则可以进一步确定回调函数的执行也导致了对系统表的篡改。因此，回调函数也可能被阻止。在这样的情形下，该驱动程序和另一驱动程序的回调函数的执行可能在计算设备100的随后引导期间被阻止。

图5图示了根据本主题的一示例的实现用于确定对计算设备中的UEFI的篡改的非暂时性计算机可读介质502的系统环境500。在一示例实现方式中，系统环境500可以是计算设备，诸如计算设备100。系统环境500包括通过通信链路506通信地耦合到非暂时性计算机可读介质502的处理资源504。在一示例中，处理资源504从非暂时性计算机可读介质502获取计算机可读指令并执行该计算机可读指令。

非暂时性计算机可读介质502可以是例如内部存储器设备或外部存储器设备。在示例实现方式中，通信链路506可以是直接通信链路，诸如任何存储器读/写接口。在另一示例实现方式中，通信链路506可以是间接通信链路，诸如网络接口。在这样的情况下，处理资源504可以通过网络508访问非暂时性计算机可读介质502。网络508可以是单个网络或多个网络的组合，并且可以使用各种不同的通信协议。

处理资源504和非暂时性计算机可读介质502也可以通信地耦合到（一个或多个）数据源510。（一个或多个）数据源510可以用于存储数据。在示例实现方式中，非暂时性计算机可读介质502包括计算机可读指令集，用于确定对诸如计算设备100之类的计算设备中的UEFI的篡改。该计算机可读指令集可以由处理资源504通过通信链路506访问，并且随后被执行以授权对计算设备100的访问。

在一示例中，非暂时性计算机可读介质502可以包括用于实现检测引擎102的指令。在一个示例中，实现检测引擎102的指令可以是可执行以检测与组件设备100的硬件组件相关联的驱动程序的执行的代码。该代码可以进一步促进检测驱动程序的执行的完成。

非暂时性计算机可读介质502可以进一步包括实现散列引擎104的指令集。在一个示例中，实现散列引擎104的指令可以是可执行以在各种实例处计算UEFI的系统表的散列的代码，其中系统表是存储计算设备的配置细节以及UEFI服务的数据结构。

此外，非暂时性计算机可读介质502可以包括实现确定引擎106的指令集。在一个示例中，实现确定引擎106的指令可以是可执行以比较由散列引擎104计算的散列从而确定对UEFI的系统表的篡改的代码。

在本主题的一示例中，实现检测引擎102的指令可以在计算设备的预操作系统（OS）初始化期间在驱动程序执行环境（DXE）阶段中检测与计算设备的硬件组件相关联的驱动程序的执行。

基于检测到驱动程序的执行，实现散列引擎104的指令可以计算系统表的第一驱动程序散列。

实现检测引擎102的指令然后可以检测驱动程序的执行的完成。基于该检测，实现散列引擎104的指令可以计算系统表的第二驱动散列。此后，实现确定引擎106的指令可以比较第一驱动程序散列和第二驱动程序散列，并且可以将比较的结果存储在（一个或多个）数据源510中。

随后，实现检测引擎102的指令可以检测与计算设备的另一组件相关联的另一驱动程序的回调函数的执行。基于该检测，实现散列引擎104的指令可以计算系统表的第一回调函数散列。

实现检测引擎102的指令然后可以检测回调函数的执行的完成。基于该检测，实现散列引擎104的指令可以计算第二回调函数散列。此后，实现确定引擎106的指令可以比较第一回调函数散列和第二回调函数散列，并且将比较的结果存储在（一个或多个）数据源510中。

基于第一和第二驱动程序散列以及第一和第二回调函数散列中的至少一个的比较，实现确定引擎106的指令可以确定对UEFI的系统表的篡改。如果确定第一和第二驱动程序散列不匹配或者第一和第二回调函数散列不匹配，则实现确定引擎106的指令可以确定系统表已经被篡改。

在这样的情形下，实现确定引擎106的指令可以阻止该驱动程序和另一驱动程序的回调函数中的至少一个。

阻止该驱动程序和另一驱动程序的回调功能中的至少一个可以避免在计算设备100的随后引导期间执行恶意代码，从而确保计算设备100的UEFI的完整性。

尽管本主题的示例已经以特定于方法和/或结构特征的语言进行了描述，但是要理解，本主题不限于所描述的具体方法或特征。而是，这些方法和具体特征是作为本主题的示例来公开和解释的。

Claims

1.一种方法，包括：

在具有统一可扩展固件接口（UEFI）的计算设备的引导期间，检测与计算设备的硬件组件相关联的驱动程序的执行；

计算UEFI的系统表的第一驱动程序散列，其中所述系统表是存储计算设备的配置细节以及UEFI服务的数据结构；

检测驱动程序的执行的完成；

在驱动程序的执行完成时，计算系统表的第二驱动程序散列；以及

比较第一驱动程序散列和第二驱动程序散列，以确定对UEFI的系统表的篡改。

2.如权利要求1所述的方法，进一步包括基于确定对UEFI的系统表的篡改来阻止驱动程序。

3.如权利要求2所述的方法，进一步包括在计算设备的随后引导期间阻止驱动程序的执行。

4.如权利要求1所述的方法，进一步包括：

标识耦合到计算设备的视频输出设备；以及

在确定对系统表的篡改时，在视频输出设备上显示提供驱动程序的细节的通知。

5.如权利要求1所述的方法，进一步包括撤销由驱动程序对系统表所做出的修改。

6.如权利要求1所述的方法，其中所述驱动程序的执行是在计算设备的引导期间在驱动程序执行环境（DXE）阶段中被检测的。

7.如权利要求6所述的方法，其中所述驱动程序是DXE驱动程序和UEFI驱动程序中的一个。

8.如权利要求6所述的方法，进一步包括：

在DXE阶段内触发系统管理模式（SMM），其中触发SMM将计算设备的处理器的状态保存在与其耦合的随机存取存储器（RAM）的安全区域中；以及

将第一驱动程序散列和第二驱动程序散列存储在RAM的安全区域中。

9.如权利要求1所述的方法，进一步包括：

检测与计算设备的另一硬件组件相关联的另一驱动程序的回调函数的执行；

计算系统表的第一回调函数散列；

检测回调函数的执行的完成；

在检测到回调函数的完成时，计算系统表的第二回调函数散列；

将第一回调函数散列与第二回调函数散列进行比较；以及

基于所述比较，确定对UEFI的系统表的篡改。

10.如权利要求9所述的方法，进一步包括在计算设备的随后引导期间阻止回调函数的执行。

11.一种系统，包括：

检测引擎，用于在具有统一可扩展固件接口（UEFI）的计算设备的预操作系统（OS）初始化期间在驱动程序执行环境（DXE）阶段中检测与计算设备的硬件组件相关联的驱动程序的回调函数的执行；

耦合到检测引擎的散列引擎，用于：

计算UEFI的系统表的第一回调函数散列，其中所述系统表是存储计算设备的配置细节以及UEFI服务的数据结构；

在检测到回调函数的执行的完成时，计算系统表的第二回调函数散列；以及

耦合到散列引擎的确定引擎，用于：

查明第一回调函数散列是否不同于第二回调函数散列，以确定对UEFI的系统表的篡改。

12.如权利要求11所述的系统，其中所述检测引擎耦合到DXE调度程序，其中所述DXE调度程序在计算设备的预OS初始化期间发现并执行与计算设备的多个硬件组件相关联的多个驱动程序。

13.如权利要求11所述的系统，进一步包括修改引擎，用于基于对UEFI的系统表的篡改的确定来撤销对系统表所做出的修改。

14.一种非暂时性计算机可读介质，包括可由处理资源执行的指令，用于：

在具有统一可扩展固件接口（UEFI）的计算设备的预操作系统（OS）初始化期间在驱动程序执行环境（DXE）阶段中检测与计算设备的硬件组件相关联的驱动程序的执行；

检测驱动程序的执行的完成；

在驱动程序的执行完成时，计算系统表的第二驱动程序散列；

将第一驱动程序散列与第二驱动程序散列进行比较；

在计算设备的预OS初始化期间在DXE阶段中检测与计算设备的另一硬件组件相关联的另一驱动程序的回调函数的执行；

计算系统表的第一回调函数散列；

检测回调函数的执行的完成；

在回调函数的执行完成时，计算系统表的第二回调函数散列；

将第一回调函数散列与第二回调函数散列进行比较；以及

基于第一和第二驱动程序散列以及第一和第二回调函数散列中的至少一个的比较，确定对UEFI的系统表的篡改。

15.如权利要求14所述的非暂时性计算机可读介质，进一步包括用于在计算设备的随后引导期间阻止驱动程序和另一驱动程序的回调函数中的至少一个的执行的指令。