Phoenix quiet these years

A quick personal note to Phoenix, one of the big IBVs:

Is everything ok at Phoenix? Or is it that you’re doing so good these days you don’t need to keep the public informed of your company’s activities? It is nice to see talks at UEFI Forum meeetings, but please get someone to update your blogs and press release pages. Your press release and event pages haven’t been updated since 2013. Your blog hasn’t been updated since 2010. Even Tim Lewis’  of Phoenix’s personal blog hasn’t  been updated since 2014. If this kind of interactivity with the public is an indication, I’m worried about the next firmware security update that impacts Phoenix systems, if nobody is updating things there anymore. Thanks!

Microsoft Windows HSTI (Hardware Security Test Interface)

I just noticed that Microsoft has a “Hardware Security Testability Specification”, still at version 1.0, which defines the Microsoft Windows “Hardware Security Test Interface” (HSTI). The Windows Hardware Certification Program is a self-testing and certification process for Windows OEMs and IHVs. The OEMs/IHVs run some tests, pass them, upload the test log output showing the passing, the vendor gets their code signed and/or they won’t get their marketing logo. Though the test name and the group  name have changed, these tests have been around since the beginning of Windows NT. The tests have grown over time to cover more system components, and certification and logo requirements have gotten more tied to passing test results. As these tests are only useful for Windows-centric IHVs and OEMs, I’ve not paid much attention to what firmware tests are available. These days, there are tests for chip vendors and for IBVs (Independent BIOS Vendors), in addition to OEMs and IHVs. It looks like they have a few UEFI-centric tests regarding Secure Boot, and dealing with system suspend/resume.

Jeremiah Cox of Microsoft gave a talk at the Summer 2013 UEFI Forum plugfest (Summerfest): “Validating Hardware Security Through Firmware Interfaces“, see below for URL to slides.

Excerpts from the MSDN web page:

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.

Beyond Canonical’s FirmWare Test Suite (FWTS) tool for Ubuntu systems, I wonder if Linux Foundation (and FreeBSD Foundation) have anything close to this testing and certification policy for (not just a test), to help encourage silicon vendors, IBVs, IHVs, and OEMs to best (and most securely) work with Linux (and FreeBSD). In addition to passing FWTS, Intel-based systems should also have to pass current CHIPSEC release before Linux or FreeBSD should touch the platform.

This also reminds me of my last blog post, about getting CHIPSEC results more widely available for consumer’s pre-sales knowledge, depending on the strength of these Windows tests, Microsoft may have some OEM/IBV test results that I wish they’d share (but they never would share that kind of data about their Partner, of course).

For the good of all OSes, not just Windows, I wish Microsoft would add CHIPSEC to their test suites, to force OEMs to pass CHIPSEC. I wonder if CHIPSEC works using IronPython when run as an OS-level app on Windows. 🙂

More Information:

Jeff Thomas leaves Sage Engineering

Hmm, I don’t understand what is happening at Sage Engineering, it looks like there are are multiple coreboot people who are looking for a job(?), see below bold sentences (emphasis mine):

I woke up this morning dreaming about different chipsets and boot solutions, though quickly realizing there was no longer a reason. Because today I’m writing my last blog for Sage Electronic Engineering. Along with myself, the change the technical to non-technical writer, there are a lot of fine coreboot engineers now looking for work. I’d like to thank everyone who followed this blog, notably Vincent Zimmer at Intel, as it has meant a lot to me, as well as my company. I’d also like to thank Sage CEO Scott Hoot and VP of Marketing Dennis Batchelor for having me along, as well as the numerous engineers and managers, Drew Jensen and Steve Goodrich come to mind, I’ve bothered with questions along the way. I enjoyed working here very much. Mostly, I’d like to note that I never did get around to writing about owner/engineer  Kimarie Hoot, who certainly deserves an award for both a woman in software and a woman in business. Some publicist I am. Kimarie is much more than a credit to her gender and electronic engineering. I’m not sure what’s going to happen to some very fine engineering here at Sage, especially the SageBIOS for Intel and AMD processors, but I’d like to believe it will be available in some form. Seems like an incredible waste otherwise. Everyone I’ve worked with here has been a credit to x86 embedded development. When they asked me what I knew about BIOS and firmware when I interviewed here, I said, “Well I’ve updated BIOS on my laptop, pretty much know what that does, and I’ve flashed a couple of routers — that’s about it.” Hopefully, I’ve found my way around a bit since then. Anyway, my last stab at humor, and there have been some outstanding failures in this department, comes from the Hitchhiker’s Guide to the Galaxy series. So long, and thanks for all the fish.