HSTI 的一个问题

这一切的起因是 MS WHQL测试的要求，为了确保 Connected Standby 功能，需要验证 secure 方面的设定（我目前还很难想象二者之间的关系，也许是在一睡一醒之间会放松警惕，所以MS要求我们特别注意？）

这个测试被称作System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning 【参考1】。

为了完成这个测试 MS （我相信这种事情肯定不止MS一个人干的）引入新功能： HSTI Hardware Security Test Interface。

关于这个功能，在【参考2】有如下解释：
“HSTI helps avoid misconfiguration of security features on devices running Windows. Thus, HSTI provides better assurance of compliance with Windows Hardware Security Requirements. HSTI aims to simplify the interface for designing tests to ensure compliance, reducing the effort required to comply with Windows Hardware Security Requirements. The results of HSTI tests will be consumed by Windows Certification Tests and can be used to verify that devices have been properly configured to enable supported security features. These tests may be used to identify unsecure engineering devices in the field; for example, engineering devices which may contain unsecure test keys. The results of these tests may be used by the Windows operating system to display a watermark (or similar indicator) on unsecured devices. The IHV will develop reference security designs for their platforms that comply with the Windows Compatibility Requirements. In addition, IHVs and IBVs will also implement programmatic tests that verify proper enablement of the reference security implementations and report the results via the Hardware Security Test Interface. These tests are delivered to OEMs & ODMs as compiled modules (not source) and should work without modification. If an OEM/ODM deviates from reference security designs, these test modules may report failures, and the OEM/ODM will need to contact Microsoft to review the modifications and implement an additional HSTI instance that reports these exceptions. OEMs should be able to leverage these security modules with no modification required by following the reference design and documentation. OEMs who wish to add additional security modules, or modify the behavior of any security module, must undergo a design review with Microsoft. Silicon suppliers and IBVs who support Connected Standby systems must implement the platform independent interfaces for querying the respective hardware and firmware security states of their reference platforms. These implementations must be delivered as compiled modules. It is recommended that these modules be signed, and that a signature check is performed when they are run. The purpose is to query the hardware and firmware designs and states to report proper security provisioning of the platform. If an OEM wants to provide an alternate implementation of HSTI tested security features the OEM may provide additional tests. OEM security checks must at least fully cover one IHV or IBV security test. Before use, OEMs must submit to a design review by Microsoft and are subject to the same Documentation and Tool disclosure requirements as other HSTI test providers. Upon approval from Microsoft, the OEM may include security tests that extend upon the IHV and IBV tests. Note that OEM attestation is not required as part of the HSTI design. HSTI is not a list of requirements for OEMs; it is an interface to guarantee effective programmatic security testing of firmware, hardware, and configuration parameters. Silicon and firmware suppliers should make available to Microsoft all necessary security-related reference documentation and tools that they provide to OEMs. This documentation and tools should be made available no later than they are provided to Windows OEMs. This should include, but is not limited to, all documentation and tools related to fusing, installing and updating firmware, firmware and boot recovery, hardware diagnostics, firmware diagnostics, & boot diagnostics. This documentation and tools provided should be fully sufficient to perform HSTI checks in a lab environment.”

相信各位和我一样，看完了之后依然一头雾水。

根据我的理解，具体动作如下：BIOS 自己检查安全项目，将结果存放在内存中 HSTI Table，这也是双方协商好确定的 Windows 接口，通过它，Windows可以得知当前系统上的安全设定，比如Boot Guard 是否打开，SPI 是否已经设置保护等等。对于WHQL 来说只是读取这个Table而已。

实例：我拿到的测试报告有下面的Fail项目：

Error 0x00060002 Platform Security Specification - CPU Security Configuration - Pre-production silicon in use

查看代码，是可以在你的 codebase 中找到这个字符串的定义的，比如：

#define LABZ_ERROR_CODE_2 L"0x00060002"
#define LABZ_ERROR_STRING_2 L" Pre-production silicon in use\r\n"

然后再检查引用这个字符串的代码：

DEBUG ((DEBUG_INFO, " 2. Sample Part \n"));

if ((ProcessorReadMsr64 (CpuX, MSR_LABZ_INFO) & BIT21) != 0) {
DEBUG ((DEBUG_INFO, "Fail: This is a sample part\n"));
HstiErrorString = BuildHstiErrorString (LABZ_ERROR_CODE_2 ,HSTI_CPU_SECURITY_CONFIGURATION, LABZ_ERROR_STRING_2 );
Result = FALSE;
FreePool (HstiErrorString);
}

就是说，BIOS 根据ProcessorReadMsr64 (CpuX, MSR_LABZ_INFO) & BIT21!=0这个条件判断当前系统是否为 Sample。如果是的话，就将这个ERROR 记录下来存放在HSTI 中。

原理就是这样，如果单纯的为了通过测试，可以去修改BIOS，修改自检的动作。比如，修改上面的条件，让BIOS不去记录这个错误从而通过WHQL。特别注意，一个错误可能是很多不同条件检查出来的结果。比如，检查 EC access, CSME access 的时候都会报告下面这个错误

Error 0x0001000A Platform Security Specification - SPI Flash Configuration - SPI Region Access Rights Invalid

下面再介绍如何检查修改是否生效：

1. 最最稳妥的就是拿去重做WHQL测试；
2. 如果细心的话，会注意到上面的代码是有Debug信息输出的，可以对照UART输出的DEBUG信息检查，如果修改后，如果没有这个信息，那么就是正确的了。推荐使用这个方法，查看Log对于定位错误的位置非常有帮助；
3. 需要检查你的codebase是否为最新版，很多检查寄存器的值并非不正确，只是你手中的版本没有包含这个值而已；
4. 因为HSTI是UEFI 定义的结构，还可以在UEFI 下面进行读取。这里推荐jyao1 编写的一个工具【参考3】，能够在Shell下展示这个结构体的信息。我重新在UDK2015上编译了一次，非常好用，这里送上代码和X64的EFI。
5. 如果有问题，直接问Intel。 Insyde 对此不清楚。

上面提到的完整代码和X64的EFI 程序下载 hstiwsmtdump

就是这样，祝好运。

参考：
1. https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx
2. https://firmwaresecurity.com/2015/08/03/microsoft-windows-hsti-hardware-security-test-interface/ 这里提到的出处是 MSDN，但是原始界面已经不复存在了
3. https://github.com/jyao1/EdkiiShellTool/tree/master/EdkiiShellToolPkg

特别声明：本文是一篇小说，不可作为技术指导以及参考，非专业人士请不要用来检测使用的机器。