用于验证基于UEFI的BIOS的安全性的方法和设备与流程
本公开涉及计算机安全的技术领域，具体地涉及用于验证基于uefi的bios的安全性的方法和设备。
背景技术：
近年来，随着计算机技术和互联网的快速发展，计算机的安全性变得越来越重要。使用intel公司的cpu（中央处理单元）的计算机是目前主流的计算平台，涉及到互联网公司内的数万计的个人电脑与十万计的服务器，而基于uefi（统一可扩展固件接口）的bios则是这些使用intel公司的cpu的个人电脑与服务器的初始化启动代码，可以说是整个计算平台的根基。如果所述bios中存在安全漏洞，则整个计算平台的安全性便无从谈起。目前来说，利用bios中存在的安全漏洞对计算机或服务器进行攻击或入侵是黑客常用的手段之一。然而，现有技术却很难确认intel平台下的基于uefi的bios的安全性，因此也难以避免使用存在潜在漏洞的bios，从而使得计算机或服务器的信息安全受到潜在威胁。
技术实现要素：
有鉴于此，本公开提供了用于验证基于uefi的bios的安全性的方法和设备，期望克服上面提到的部分或全部缺陷以及其它可能的缺陷。
根据本公开的第一方面，提供了一种用于验证基于uefi的bios的安全性的方法。所述方法包括：获取基于uefi的bios镜像；解析所述bios镜像，以得到所述bios镜像的分层解析结构，所述分层解析结构包括一个或多个固件卷，每个固件卷包括一个或多个固件文件，所述固件文件包括数据固件文件和可执行固件文件；以及基于所述分层解析结构确定所述bios的安全性。
在一些实施例中，基于所述分层解析结构确定所述bios的安全性可以包括：利用安全性判断模型来确定所述bios的安全性。所述安全性判断模型可以包括如下条件：(a)初始化引导代码块清单中定义的bios镜像的初始化启动阶段执行文件的地址范围完全包含bios镜像中sec阶段和pei阶段的可执行固件文件所在固件卷的地址范围；(b)pei阶段的bootguard实现所读取的dxe阶段的地址范围完全包含dxe阶段的可执行固件文件的地址范围的集合；(c)pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程，以及在所述bootguard实现中的散列验证阶段仅引入单一正确的散列验证对象以与bootguard实现中的散列算法得到的待验证对象进行对比并且不存在变量覆盖；(d)dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程，以及在所述secureboot实现中的散列验证阶段仅引入单一正确的散列验证对象以与secureboot实现中的散列算法得到的另一待验证对象进行对比并且不存在变量覆盖。
在一些实施例中，所述方法还包括：如果上述条件(a)-(d)全部被满足，则确定所述bios为安全的。
在一些实施例中，所述方法还包括：通过如下步骤得到dxe阶段的可执行固件文件的地址范围的集合：确定涵盖dxe阶段的可执行固件文件所在的所有固件卷的地址范围，并从中排除所述所有固件卷中的数据固件文件对应的地址范围。
在一些实施例中，所述方法还包括：通过以下步骤确定pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程：跟踪pei阶段的bootguard实现的流程以生成针对bootguard实现的指令与上下游程序控制流图；从所述针对bootguard实现的指令与上下游程序控制流图中获取bootguard实现中的散列算法实现的控制流图；以及，确定所述bootguard实现中的散列算法实现的控制流图属于标准散列算法实现的控制流图集。
在一些实施例中，所述方法还包括：通过以下步骤确定pei阶段的bootguard实现中的散列验证阶段不存在变量覆盖：确定所述bootguard实现中散列算法终结指令与散列验证指令间没有修改过bootguard实现中的散列算法得到的所述待验证对象；以及，确定在通过散列验证指令得到结果后，针对该结果的变量没有被重新赋值。
在一些实施例中，所述方法还包括：通过以下步骤确定dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程：跟踪dxe阶段的secureboot实现的流程以生成针对secureboot实现的指令与上下游程序控制流图；从所述针对secureboot实现的指令与上下游程序控制流图中获取secureboot实现中的散列算法实现的控制流图；以及，确定所述secureboot实现中的散列算法实现的控制流图属于标准散列算法实现的控制流图集。
在一些实施例中，所述方法还包括：通过以下步骤确定secureboot实现中的散列验证阶段不存在变量覆盖：确定所述secureboot实现中的散列算法终结指令与散列验证指令间没有修改过secureboot实现中的散列算法得到的所述另一待验证对象；以及确定在通过所述散列验证指令得到结果后，针对该结果的变量没有被重新赋值。
在一些实施例中，所述方法还包括：响应于确定不存在与该bios具有相同可执行固件文件且已确定其安全性的另一bios，则利用安全判断模型来确定所述bios的安全性。
在一些实施例中，所述方法还包括：响应于确定存在与该bios具有相同可执行固件文件且已确定其安全性的另一bios，则将所述另一bios的安全性确定为该bios的安全性。
根据本公开的第二方面，提供了一种用于验证基于uefi的bios的安全性的设备。所述设备包括：获取模块，被配置成获取基于uefi的bios镜像；解析模块，被配置成解析所述bios镜像，以得到所述bios镜像的分层解析结构，所述分层解析结构包括一个或多个固件卷，每个固件卷包括一个或多个固件文件，所述固件文件包括数据固件文件和可执行固件文件；以及，安全确定模块，被配置成基于所述分层解析结构确定所述bios的安全性。
在一些实施例中，所述安全确定模块可以被配置成利用安全性判断模型来确定所述bios的安全性。所述安全性判断模型包括如下条件：(a)初始化引导代码块清单中定义的bios镜像的初始化启动阶段执行文件的地址范围完全包含bios镜像中sec阶段和pei阶段的可执行固件文件所在固件卷的地址范围；(b)pei阶段的bootguard实现所读取的dxe阶段的地址范围完全包含dxe阶段的可执行固件文件的地址范围的集合；(c)pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程，以及在所述bootguard实现中的散列验证阶段仅引入单一正确的散列验证对象以与bootguard实现中的散列算法得到的待验证对象进行对比并且不存在变量覆盖；(d)dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程，以及在所述secureboot实现中的散列验证阶段仅引入单一正确的散列验证对象以与secureboot实现中的散列算法得到的另一待验证对象进行对比并且不存在变量覆盖。
在一些实施例中，所述安全确定模块可以被配置成响应于确定所述条件(a)-(d)全部被满足，则确定所述bios为安全的。
根据本公开的第三方面，提供了一种计算设备，包括：处理器；以及，存储器，其被配置为在其上存储有计算机可执行指令，当计算机可执行指令被处理器执行时执行如上面所述的任一方法。
根据本公开的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，当所述计算机可执行指令被执行时，执行如上面所述的任一方法。
在本公开要求保护的用于验证基于uefi的bios的安全性的方法和设备中，通过基于bios的分层解析结构，能够全面详细地验证bios的安全性。特别是，通过基于bios的分层解析结构检测sec、pei、dxe阶段的安全性，更能够全面详细地验证bios的安全性。在本发明的实施例中，通过进一步全面分析bios中散列验证覆盖面的完整性、散列算法实现的正确性、散列计算至散列验证过程的原子性、以及隐蔽生效的数字证书或散列存在的可能性，能够全面检测bios中是否存在安全保护措施配置不当、安全相关算法实现不当以及安全保护流程实施不当等造成的bios漏洞。
根据下文描述的实施例，本公开的这些和其它优点将变得清楚，并且参考下文描述的实施例来阐明本公开的这些和其它优点。
附图说明
现在将更详细并且参考附图来描述本公开的实施例，其中：
图1图示了uefi平台初始化规范中定义与平台的启动过程相关的各个阶段；
图2图示了根据本公开的一个实施例的用于验证uefibios的安全性的方法的流程图；
图3示出了根据本公开的一个实施例的uefibios镜像被解析后得到的分层解析结构的示意图；
图4图示了根据本公开的一个实施例的用于基于uefibios的分层解析结构确定所述bios的安全性的方法的示例性流程图；
图5图示了根据本公开的一个实施例的用于基于uefibios的分层解析结构确定所述bios的安全性的另一方法的示例性流程图；
图6图示了根据本公开的一个实施例的用于验证uefibios的安全性的设备的示例性结构框图；
图7图示了一个示例系统，其包括代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备。
具体实施方式
下面的说明提供用于充分理解和实施本公开的各种实施例的特定细节。本领域的技术人员应当理解，本公开的技术方案可以在没有这些细节中的一些的情况下被实施。在某些情况下，并没有示出或详细描述一些熟知的结构和功能，以避免不必要地使对本公开的实施例的描述模糊不清。在本公开中使用的术语以其最宽泛的合理方式来理解，即使其是结合本公开的特定实施例被使用的。
首先，对本公开的实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。
bios：基本输入输出系统（basicinputoutputsystem），它是一组固化到计算机内主板上一个rom芯片上的程序，它保存着计算机最重要的基本输入输出的程序、开机后自检程序和系统自启动程序，其主要功能是为计算机提供最底层的、最直接的硬件设置和控制。在下文中，基于uefi的bios被与uefibios互换地使用。
bootguard：一种基于硬件协助的bios完整性验证机制，用于保护uefibios免受非法篡改。这项技术会在硬件中创建一种可信任的启动链，即当前的启动组件会对下一个组件的完整性进行加密验证。在这条启动链中，第一个启动组件是带有微代码的intelcpu。微代码会加载进受保护的内部cpu内存，即acram（authenticatedcoderam），然后验证并执行一个由intel签名的bootguardacm（authenticatedcodemodule-验证码模块）。rsa公共密钥（用于验证acm签名）是硬编码在cpu里面的，这也是intel设计的一种技术实现。bootguardacm的运行优先于bios。
ibb：初始启动块（initialbootblock），其需要被bootguardacm验证正确性，ibb的作用是显示uefibios中sec和pei卷的内容。
ibbm:初始化引导代码块清单(initialbootblockmanifest)。
secureboot：uefi的一个子规格，其采用密钥技术防止恶意软件侵入。uefi规定：主板出厂的时候，可以内置一些可靠的公钥。然后，任何想要在这块主板上加载的操作系统或者硬件驱动程序，都必须通过这些公钥的认证。也就是说，这些软件必须用对应的私钥签署过，否则主板拒绝加载。
图1图示了uefi平台初始化规范中定义与平台的启动过程相关的各个阶段。如图1所示，uefi平台从加电到关机可以包括七个阶段：sec（安全验证）阶段，pei（efi前期初始化）阶段，dxe（驱动执行环境）阶段，bds（启动设备选择）阶段，tsl（操作系统加载前期）阶段，rt（runtime）阶段，al（系统灾难恢复期）阶段。前三个阶段sec、pei、dxe是uefi平台初始化阶段。
sec阶段是平台初始化的第一个阶段，进行初始代码运行，它接收并处理平台启动和重启信号，初始化临时存储区域以运行基于堆栈的c代码，发现、验证并传递相关参数给下一阶段（即pei阶段）。
pei阶段资源仍然十分有限，内存到了pei后期才被初始化，其主要功能是为dxe阶段准备执行环境，将需要传递到dxe阶段的信息组成hob（handoffblock）列表，最终将控制权转交到dxe阶段。
dxe阶段执行大部分平台初始化工作，例如，发现并执行初始化平台组件的驱动程序。进入此阶段时，内存已经可以被完全使用，因而此阶段可以进行大量的复杂工作。dxe阶段结束后，uefi环境已经准备完毕。
bds阶段的主要功能是初始化控制台设备以及根据设置加载和执行启动项。用户选中某个启动项（或进入默认的启动项）后，操作系统加载器启动，启动过程进入tsl阶段。
tsl阶段是操作系统加载器作为uefi应用程序运行的阶段。操作系统加载器调用exitbootservices()服务后进入rt阶段，rt阶段包括操作系统加载器后期和操作系统运行期。当系统硬件或操作系统出现严重错误不能继续正常运行时，固件会尝试修复错误，这时系统进入al阶段。
图2图示了根据本公开的实施例的用于验证基于uefi的bios的安全性的方法200的流程图。所述方法200可以被实施在服务器、与客户端（例如，客户端设备）相关联的计算设备、以及第三方计算设备等任何合适的计算设备上。如图2所示，所述方法包括如下描述的步骤201-203。
在步骤201，获取基于uefi的bios镜像。所述基于uefi的bios镜像可以从bios镜像提供商（其通常也是计算机供应商）直接获取到，也可以从提供有基于uefi的bios镜像的计算机上获取得到。作为验证服务器上运行的bios的安全性的一个示例，可以在服务器侧部署agent（代理），采集并上报服务器中当前运行的uefibios镜像。所有agent上报的镜像文件会被与服务器硬件和bios版本信息关联地归类存档数据中台，然后可以从数据中台中获取bios镜像进行验证。
在步骤202，解析所述bios镜像，以得到bios镜像的分层解析结构。所述分层解析结构包括一个或多个固件卷，每个固件卷包括一个或多个固件文件，每个固件文件还可以包括一个或多个固件段。作为示例，可以借助于开源软件uefitool来解析所述bios镜像。
图3示出了根据本公开的实施例的基于uefi的bios镜像被解析后得到的分层解析结构的示意图。如图3所示，所述bios镜像可以被解析得到这样的分层解析结构，所述分层解析结构包括一个或多个固件卷（例如，固件卷0,1,…）。每个固件卷包括一个或多个固件文件（例如，固件文件0,1,…）,每个固件文件包括最基本的单元-固件段（例如，固件段0,1，…）。
固件卷是逻辑上的固件设备，是存储数据和代码的基本存储仓库，其基本组成单元是固件文件。固件文件存储固件卷中的数据和代码，因此固件文件可以分为存储变量等数据的数据固件文件和存储代码的可执行固件文件。固件段可以分为仅包含数据的叶子段以及不直接包含数据的容器段。一个容器段（例如固件段1）可以包括多个子段（例如固件段10和11），每个子段可以是一个叶子段或容器段。固件段还可以嵌套包括新的固件卷。例如，图3中的固件段0可以包括新的固件卷00，并且固件卷00进一步包括新的固件文件(例如固件文件01)。
在步骤203，基于所述分层解析结构确定所述bios的安全性。具体地，基于所述分层解析结构中包括的固件卷和固件文件来确定所述bios的安全性，也即在固件卷和固件文件的层面上来确定所述bios的安全性。在一些实施例中，可以利用预先确定的安全性判断模型来确定所述bios的安全性，如下面详细描述的。
图4图示了根据本公开实施例的用于基于uefibios的分层解析结构确定所述bios的安全性的方法400的示例性流程图，其中可以利用如上面所描述的预先确定的安全性判断模型来确定所述bios的安全性。所述方法400例如被利用来实现如方法200中描述的步骤203。
作为示例，所述安全性判断模型包括如下条件：(a)ibbm中定义的bios镜像的初始化启动阶段执行文件的地址范围完全包含bios镜像中sec阶段和pei阶段的可执行固件文件所在固件卷的地址范围；(b)pei阶段的bootguard实现所读取的需要验证其hash正确性的dxe阶段的地址范围完全包含dxe阶段的可执行固件文件的地址范围的集合；(c)pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程，以及所述bootguard实现中的散列验证阶段仅引入单一正确的散列验证对象以与bootguard实现中的散列算法得到的待验证对象进行对比并且不存在变量覆盖；(d)dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程，以及所述secureboot实现中的散列验证阶段仅引入单一正确的散列验证对象以与secureboot实现中的散列算法得到的另一待验证对象进行对比并且不存在变量覆盖。
如上所述，前三个阶段sec、pei、dxe是操作系统启动之前的uefi平台初始化阶段，因此前三个阶段sec、pei、dxe的安全性对于bios的安全性是决定性的。在本公开的实施例中，通过基于所述分层解析结构检测sec、pei、dxe阶段的安全性，能够很好地确定和验证所述bios的安全性。
在一些实施例中，bios镜像的初始化启动阶段执行文件的地址范围可以通过读取ibbm中的ibbsegments字段定义的闪存线性地址范围而得到，并被记为
在一些实施例中，pei阶段的bootguard实现所读取的需要验证其hash正确性的dxe阶段地址范围可以通过读取变量findbootguarddxehashcontainer定义的闪存线性地址范围而得到，并被记为
作为示例，dxe阶段的可执行固件文件的地址范围的集合
如上面所述，条件(a)和条件(b)主要用于保证bios中散列验证的覆盖面的完整性，以避免bios中安全保护措施配置不当引起bios的漏洞。
应当指出，本文中的所述的一个算法的实现流程“符合”另一算法的实现流程指的是这两个算法的实现流程完全相同，或者两者的实现流程中的实现逻辑是相同的。例如，pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程可以指pei阶段的bootguard实现中的散列算法的实现流程与标准散列算法的实现流程完全相同，或者pei阶段的bootguard实现中的散列算法的实现流程与标准散列算法的实现流程中的实现逻辑是相同的。
在一些实施例中，可以通过以下步骤确定pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程。首先，跟踪pei阶段的bootguard实现的流程以生成针对bootguard实现的指令与上下游程序控制流图
作为示例，可以使用符合执行技术来跟踪pei阶段的bootguard实现的流程以生成针对bootguard实现的指令与上下游程序控制流图。作为示例，可以使用图同构算法（例如，nauty算法）来确定所述bootguard实现中散列算法实现的控制流图
在一些实施例中，可以通过以下步骤确定pei阶段的bootguard实现中的散列验证阶段不存在变量覆盖：确定所述bootguard实现中的散列算法终结指令
为清楚期间，应当指出，本文中所描述的散列算法起始指令指示开始执行散列计算，散列算法终结指令指示得到散列计算的结果，散列验证指令指示得到散列验证的结果。
因此，条件(c)中，通过确定pei阶段的bootguard实现中的散列验证阶段不存在变量覆盖，可以保证bootguard实现中的散列计算至验证过程的原子性，避免被外部程序篡改散列验证过程或结果，从而避免bios中安全保护流程实施不当引起的漏洞。
此外，条件(c)中,所述bootguard实现中的散列验证阶段仅引入单一正确的散列验证对象以与bootguard实现中的散列算法得到的待验证对象进行对比可以表明在散列验证阶段不存在一对多、多对一匹配模式，避免了在验证阶段引入隐藏散列或生效的数字证书而造成的bios漏洞。
还应当指出，dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程可以指dxe阶段的secureboot实现中的散列算法的实现流程与标准散列算法的实现流程完全相同，或者dxe阶段的secureboot实现中的散列算法的实现流程与标准散列算法的实现流程中的实现逻辑是相同的。
在一些实施例中，可以通过以下步骤确定dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程。首先，跟踪dxe阶段的secureboot实现的流程以生成针对secureboot实现的指令与上下游程序控制流图
作为示例，可以使用符合执行技术来跟踪dxe阶段的secureboot实现的流程以生成针对secureboot实现的指令与上下游程序控制流图
在一些实施例中，可以通过以下步骤确定dxe阶段的secureboot实现中的散列验证阶段不存在变量覆盖：确定所述secureboot实现中的散列算法终结指令
因此，条件(d)中，通过确定dxe阶段的secureboot实现中的散列验证阶段不存在变量覆盖，可以保证secureboot实现中的散列计算至验证过程的原子性，避免被外部程序篡改散列验证过程或结果，从而避免bios中安全保护流程实施不当引起的漏洞。
此外，条件(d)中,所述secureboot实现中的散列验证阶段仅引入单一正确的散列验证对象以与secureboot实现中的散列算法得到的所述另一待验证对象进行对比可以表明在散列验证阶段不存在一对多、多对一匹配模式，避免了在验证阶段引入隐藏散列或生效的数字证书而造成的bios漏洞。
如图4所示，所述方法400可以包括如下步骤401-404。
在步骤401，确定所述安全性判断模型中被满足的条件，即判断所述四个条件（a）-（d）中被满足的条件。
在步骤402，确定所述四个条件（a）-（d）是否全部被满足，并且响应于确定所述四个条件（a）-（d）全部被满足，则在步骤403处确定所述基于uefi的bios是安全的，即不存在安全漏洞；否则，在步骤404处，确定所述基于uefi的bios不安全，存在安全漏洞。
以上面所述的服务器场景为例，从数据中台获取bios镜像进行验证，验证完成后可以存档该版本bios镜像的可执行固件的唯一指纹字符串，并上报其安全性信息。上报的安全性信息可以例如通过移动端、web端的告警页面通知给服务器管理员或服务器所归属的用户。
图5图示了根据本公开的一个实施例的用于基于uefibios的分层解析结构确定所述bios的安全性的另一方法500的示例性流程图。所述方法500例如被利用来实现如方法200中描述的步骤203。如图5所示，所述方法包括如下描述的步骤。
在步骤501，从所述uefibios的分层解析结构获取所有的可执行固件文件。如上面所述，固件文件可以分为存储变量等数据的数据固件文件和存储代码的可执行固件文件，因此可以例如通过从所述分层解析结构剥离数据固件文件而得到所有的可执行固件文件
在步骤502，确定是否存在与该uefibios具有相同可执行固件文件且已确定其安全性的另一bios。作为示例，可以通过确定针对该uefibios的可执行固件文件的唯一指纹字符串与针对所述另一bios的可执行固件文件的唯一指纹字符串相同，来确定该uefibios与所述另一bios具有相同的可执行固件文件。作为示例，针对一个bios的可执行固件文件的唯一指纹字符串是对该bios的可执行固件文件进行散列计算得到的散列值。作为另一示例，如果确定该uefibios的可执行固件文件与所述另一bios的可执行固件文件不仅具有相同的唯一指纹字符串，而且具有相同的文件大小以及文件数量，则确定该uefibios与所述另一bios具有相同的可执行固件文件，这能够避免单纯依靠散列计算带来的小概率误判。
在步骤503，响应于确定存在与该uefibios具有相同可执行固件文件且已确定其安全性的另一bios，则将所述另一bios的安全性确定为该uefibios的安全性。例如，如果所述另一bios的安全性已确定是安全的，则该uefibios也被确定为是安全的。
在步骤504，响应于确定不存在与该uefibios具有相同可执行固件文件且已确定其安全性的另一bios，则利用如上面所述的安全判断模型来确定所述bios的安全性。作为示例，步骤504实施上面参照图4描述的方法400，其流程与上面参照图4描述的方法400的流程相同。
图6图示了根据本公开的一个实施例的用于验证基于uefi的bios的安全性的设备600的示例性结构框图。如图6所示，所述用于验证基于uefi的bios的安全性的设备600包括获取模块601、解析模块602、安全确定模块603。
所述获取模块601被配置成获取基于uefi的bios镜像。所述获取模块601可以被配置成从bios镜像提供商（其通常也是计算机供应商）直接获取所述bios镜像，也可以被配置成从提供有基于uefi的bios镜像的计算机上获取所述bios镜像。
解析模块602被配置成解析所述bios镜像，以得到所述bios镜像的分层解析结构，所述分层解析结构包括一个或多个固件卷，每个固件卷包括一个或多个固件文件。如上面所述的，所述固件文件可以包括数据固件文件和可执行固件文件。
安全确定模块603被配置成基于所述分层解析结构确定所述bios的安全性。具体地，安全确定模块603可以被配置成基于所述分层解析结构中包括的固件卷和固件文件来确定所述bios的安全性。
在一些实施例中，安全确定模块603被配置成利用预先确定的安全性判断模型来确定所述bios的安全性。作为示例，所述安全性判断模型可以包括如下条件：(a)ibbm中定义的bios镜像的初始化启动阶段执行文件的地址范围完全包含bios镜像中sec阶段和pei阶段的可执行固件文件所在固件卷的地址范围；(b)pei阶段的bootguard实现所读取的需要验证其hash正确性的dxe阶段的地址范围完全包含dxe阶段的可执行固件文件的地址范围的集合；(c)pei阶段的bootguard实现中的散列算法的实现流程符合标准散列算法的实现流程，以及所述bootguard实现中的散列验证阶段仅引入单一正确的散列验证对象以与bootguard实现中的散列算法得到的待验证对象进行对比并且不存在变量覆盖；(d)dxe阶段的secureboot实现中的散列算法的实现流程符合标准散列算法的实现流程，以及所述secureboot实现中的散列验证阶段仅引入单一正确的散列验证对象以与secureboot实现中的散列算法得到的另一待验证对象进行对比并且不存在变量覆盖。
作为示例，所述安全确定模块603被配置成响应于确定所述条件(a)-(d)全部被满足，则确定所述bios为安全的；否则，则确定所述bios为不安全的。作为示例，所述安全确定模块603被配置成在确定不存在与该bios具有相同可执行固件文件且已确定其安全性的另一bios的情况下，利用安全判断模型来确定所述bios的安全性。
图7图示了示例系统700，其包括代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备710。计算设备710可以是例如服务提供商的服务器、与客户端（例如，客户端设备）相关联的设备、片上系统、和/或任何其它合适的计算设备或计算系统。图6描述的用于验证基于uefi的bios的安全性的设备600可以采取计算设备710的形式。替换地，用于验证基于uefi的bios的安全性的设备600可以以bios安全验证应用716的形式被实现为计算机程序。
如图示的示例计算设备710包括彼此通信耦合的处理系统711、一个或多个计算机可读介质712以及一个或多个i/o接口713。尽管未示出，但是计算设备710还可以包括系统总线或其他数据和命令传送系统，其将各种组件彼此耦合。系统总线可以包括不同总线结构的任何一个或组合，所述总线结构诸如存储器总线或存储器控制器、外围总线、通用串行总线、和/或利用各种总线架构中的任何一种的处理器或局部总线。还构思了各种其他示例，诸如控制和数据线。
处理系统711代表使用硬件执行一个或多个操作的功能。因此，处理系统711被图示为包括可被配置为处理器、功能块等的硬件元件714。这可以包括在硬件中实现为专用集成电路或使用一个或多个半导体形成的其它逻辑器件。硬件元件714不受其形成的材料或其中采用的处理机构的限制。例如，处理器可以由（多个）半导体和/或晶体管（例如，电子集成电路（ic））组成。在这样的上下文中，处理器可执行指令可以是电子可执行指令。
计算机可读介质712被图示为包括存储器/存储装置715。存储器/存储装置715表示与一个或多个计算机可读介质相关联的存储器/存储容量。存储器/存储装置715可以包括易失性介质（诸如随机存取存储器（ram））和/或非易失性介质（诸如只读存储器（rom）、闪存、光盘、磁盘等）。存储器/存储装置715可以包括固定介质（例如，ram、rom、固定硬盘驱动器等）以及可移动介质（例如，闪存、可移动硬盘驱动器、光盘等）。计算机可读介质712可以以下面进一步描述的各种其他方式进行配置。
一个或多个i/o接口713代表允许向计算设备710输入命令和信息并且可选地还允许使用各种输入/输出设备将信息呈现给用户和/或其他组件或设备的功能。输入设备的示例包括键盘、光标控制设备（例如，鼠标）、麦克风（例如，用于语音输入）、扫描仪、触摸功能（例如，被配置为检测物理触摸的容性或其他传感器）、相机（例如，可以采用可见或不可见的波长（诸如红外频率）将不涉及触摸的运动检测为手势）等等。输出设备的示例包括显示设备（例如，监视器或投影仪）、扬声器、打印机、网卡、触觉响应设备等。因此，计算设备710可以以下面进一步描述的各种方式进行配置以支持用户交互。
计算设备710还包括bios安全验证应用716。bios安全验证应用716可以例如是关于图6描述的用于验证基于uefi的bios的安全性的设备600的软件实例，并且与计算设备710中的其他元件相组合地实现本文描述的技术。
本文可以在软件硬件元件或程序模块的一般上下文中描述各种技术。一般地，这些模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元素、组件、数据结构等。本文所使用的术语“模块”，“功能”和“组件”一般表示软件、固件、硬件或其组合。本文描述的技术的特征是与平台无关的，意味着这些技术可以在具有各种处理器的各种计算平台上实现。
所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上或者跨某种形式的计算机可读介质传输。计算机可读介质可以包括可由计算设备710访问的各种介质。作为示例而非限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。
与单纯的信号传输、载波或信号本身相反，“计算机可读存储介质”是指能够持久存储信息的介质和/或设备，和/或有形的存储装置。因此，计算机可读存储介质是指非信号承载介质。计算机可读存储介质包括诸如易失性和非易失性、可移动和不可移动介质和/或以适用于存储信息（诸如计算机可读指令、数据结构、程序模块、逻辑元件/电路或其他数据）的方法或技术实现的存储设备之类的硬件。计算机可读存储介质的示例可以包括但不限于ram、rom、eeprom、闪存或其它存储器技术、cd-rom、数字通用盘（dvd）或其他光学存储装置、硬盘、盒式磁带、磁带，磁盘存储装置或其他磁存储设备，或其他存储设备、有形介质或适于存储期望信息并可以由计算机访问的制品。
“计算机可读信号介质”是指被配置为诸如经由网络将指令发送到计算设备710的硬件的信号承载介质。信号介质典型地可以将计算机可读指令、数据结构、程序模块或其他数据体现在诸如载波、数据信号或其它传输机制的调制数据信号中。信号介质还包括任何信息传递介质。术语“调制数据信号”是指以这样的方式对信号中的信息进行编码来设置或改变其特征中的一个或多个的信号。作为示例而非限制，通信介质包括诸如有线网络或直接连线的有线介质以及诸如声、rf、红外和其它无线介质的无线介质。
如前所述，硬件元件714和计算机可读介质712代表以硬件形式实现的指令、模块、可编程器件逻辑和/或固定器件逻辑，其在一些实施例中可以用于实现本文描述的技术的至少一些方面。硬件元件可以包括集成电路或片上系统、专用集成电路（asic）、现场可编程门阵列（fpga）、复杂可编程逻辑器件（cpld）以及硅中的其它实现或其他硬件设备的组件。在这种上下文中，硬件元件可以作为执行由硬件元件所体现的指令、模块和/或逻辑所定义的程序任务的处理设备，以及用于存储用于执行的指令的硬件设备，例如，先前描述的计算机可读存储介质。
前述的组合也可以用于实现本文所述的各种技术和模块。因此，可以将软件、硬件或程序模块和其它程序模块实现为在某种形式的计算机可读存储介质上和/或由一个或多个硬件元件714体现的一个或多个指令和/或逻辑。计算设备710可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，例如通过使用处理系统的计算机可读存储介质和/或硬件元件714，可以至少部分地以硬件来实现将模块实现为可由计算设备710作为软件执行的模块。指令和/或功能可以由一个或多个制品（例如，一个或多个计算设备710和/或处理系统711）可执行/可操作以实现本文所述的技术、模块和示例。
在各种实施方式中，计算设备710可以采用各种不同的配置。例如，计算设备710可以被实现为包括个人计算机、台式计算机、多屏幕计算机、膝上型计算机、上网本等的计算机类设备。计算设备710还可以被实现为包括诸如移动电话、便携式音乐播放器、便携式游戏设备、平板计算机、多屏幕计算机等移动设备的移动装置类设备。计算设备710还可以实现为电视类设备，其包括具有或连接到休闲观看环境中的一般地较大屏幕的设备。这些设备包括电视、机顶盒、游戏机等。
本文描述的技术可以由计算设备710的这些各种配置来支持，并且不限于本文所描述的技术的具体示例。功能还可以通过使用分布式系统、诸如通过如下所述的平台722而在“云”720上全部或部分地实现。
云720包括和/或代表用于资源724的平台722。平台722抽象云720的硬件（例如，服务器）和软件资源的底层功能。资源724可以包括在远离计算设备710的服务器上执行计算机处理时可以使用的应用和/或数据。资源724还可以包括通过因特网和/或通过诸如蜂窝或wi-fi网络的订户网络提供的服务。
平台722可以抽象资源和功能以将计算设备710与其他计算设备连接。平台722还可以用于抽象资源的分级以提供遇到的对于经由平台722实现的资源724的需求的相应水平的分级。因此，在互连设备实施例中，本文描述的功能的实现可以分布在整个系统700内。例如，功能可以部分地在计算设备710上以及通过抽象云720的功能的平台722来实现。
应当理解，为清楚起见，参考不同的功能模块对本公开的实施例进行了描述。然而，将明显的是，在不偏离本公开的情况下，每个功能模块的功能性可以被实施在单个模块中、实施在多个模块中或作为其它功能模块的一部分被实施。例如，被说明成由单个模块执行的功能性可以由多个不同的模块来执行。因此，对特定功能模块的参考仅被视为对用于提供所描述的功能性的适当模块的参考，而不是表明严格的逻辑或物理结构或组织。因此，本公开可以被实施在单个模块中，或者可以在物理上和功能上被分布在不同的模块和电路之间。
将理解的是，尽管第一、第二、第三等术语在本文中可以用来描述各种设备、元件、或部件，但是这些设备、元件、或部件不应当由这些术语限制。这些术语仅用来将一个设备、元件、或部件与另一个设备、元件、或部件相区分。
尽管已经结合一些实施例描述了本公开，但是其不旨在被限于在本文中所阐述的特定形式。相反，本公开的范围仅由所附权利要求来限制。附加地，尽管单独的特征可以被包括在不同的权利要求中，但是这些可以可能地被有利地组合，并且包括在不同权利要求中不暗示特征的组合不是可行的和/或有利的。特征在权利要求中的次序不暗示特征必须以其工作的任何特定次序。此外，在权利要求中，词“包括”不排除其它元件，并且不定冠词“一”或“一个”不排除多个。权利要求中的附图标记仅作为明确的例子被提供，不应该被解释为以任何方式限制权利要求的范围。
- 还没有人留言评论。精彩留言会获得点赞！