The PC industry has followed an interesting arc, beginning with the hardware and firmware details of the original IBM PC http://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf and the closed source Microsoft (MS) operating system MS/DOS https://github.com/microsoft/MS-DOS. The former allowed for the ability to have clones of the IBM PC, whereas the latter ensured some consistency in the platform design as compatibility with DOS, and then Windows, helped provide for the open platform that non-MS OS's like Linux today enjoy.
Was the distinction between MS as an OS vendor (OSV) and the industry as a platform provider always so stark? In fact, the existence of MS-written firmware, as one example, has had various examples spanning the 90's up through today's news.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To begin:
In the early days of Windows NT, including 3.51 and 4.0, Microsoft wrote the ARC boot firmware for their DEC Alpha and MIPS NT platforms. ARC stands for Advanced RISC Computing https://en.wikipedia.org/wiki/Advanced_RISC_Computing and the document http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf provided guidance on both platform hardware and firmware. A couple of MS engineers wrote the first ARC firmware and the ARC specification, along with IEEE 1275 Open Firmware (OF) https://www.openfirmware.info/data/docs/of1275.pdf, were considered as a solution for 'how to boot Itanium' during the early days of the IBI/EFI specification. 1275 came up because the PowerPC port of NT booted via OF. EFI ended up looking more like ARC, see similarity between the ARC Firmware Function Vector and UEFI System Table, although OF does have some advantages, especially for security https://www.cs.cornell.edu/~kozen/Papers/acsac.pdf.
Another interesting aspect of the ARC Alpha firmware was that the NT NDIS miniport drivers from NT were embedded in the firmware for purposes of pre-OS networking, such as network booting. Other than boot loaders like U-Boot which liberally leverages portions of device driver code, this OS and firmware code sharing helps solve one of the main challenges of boot firmware, namely having to create a firmware version of a device driver for the block, network, and console services in the pre-OS and another variant for the OS runtime.
|
|
\/
Fast forward to the early 2000's. At that time there was a project called FlexGo https://en.wikipedia.org/wiki/Microsoft_FlexGo which allowed for a metered, or subscription PC. There was MS firmware integrated into the code morpher, or microcode-like firmware of the Transmeta device https://en.wikipedia.org/wiki/Transmeta https://www.extremetech.com/extreme/76602-amd-to-resell-transmetas-payasyougo-chip. For some of the standard PC's at the time, there was exploration of having the monitoring agent from MS as an additional handler in System Management Mode (SMM) of the BIOS
|
|
\/
In the early 2010's, the industry was moving from a TPM 1.2 to 2.0. One of the learning's from the 1.2 era was that the specification for the commands lent themselves to various interpretations. As such, the TPM 2.0 specification was written in 'literate code' where the C based implementation of the commands could be extracted. The latter C code has formed the underlying implementation https://github.com/microsoft/ms-tpm-20-ref for all of the integrated and discrete 2.0 devices. This code was born of the 'firmware TPM' work described in the technical report https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2015-84.pdf.
|
|
\/
In the 20-teens, there emerged from Microsoft Project Mu for BIOS https://microsoft.github.io/mu/. Although this is officially referred to as a downstream fork of EDKII on tianocore.org, there are many unique aspects, especially features like DFCI in https://github.com/microsoft/mu_plus.
A more recent example includes MS writing the SMM supervisor for AMD SecureCore PC https://www.microsoft.com/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/ variant mentioned during OSFC '20 'hallway chat.'
And for the broader industry MS wrote many SMM audit and checking tools in Mu to help prepare the OEM ecosystem for having their handlers running in the jailed context of the SecureCore PC SMm supervisor.
|
|
\/
In the future, MS hardware Pluton hardware and firmware https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ may be even more deeply integrated.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Beyond the long run of the MS examples above you can see a similar, albeit shorter in time, arc for Google, especially Google as an OSV with respect to ChromeOS. It begins with the Google Chromebooks leveraging coreboot + vboot https://www.coreboot.org/ where Google employees are many of the upstream maintainers.
|
|
\/
More recently, the Titan/OpenTitan https://opentitan.org/ has emerged. This is a root of trust with the CPU based upon RISC-V and the operating system based upon the Tock OS https://github.com/google/tock-on-titan written in Rust. Interesting stuff.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And you cannot have firmware without hardware, of course. Google Titan-M and the OpenTitan are one example.
For Microsoft, MS already has its XBox360 https://en.wikipedia.org/wiki/Xbox_360_technical_specifications and XBox One https://en.wikipedia.org/wiki/Xbox_One, which were custom PowerPC "Watermoose" and AMD "Jaguar" based SOC's, respectively.
There are also always rumors in the air for MS, such as recent one on ARM https://arstechnica.com/gadgets/2020/12/microsoft-may-be-developing-its-own-in-house-arm-cpu-designs/ and earlier one on custom designs like E2 https://www.theregister.com/2018/06/18/microsoft_e2_edge_windows_10/.
For Google we already have ample public details on their Tensor Processing Unit (TPU) https://semiengineering.com/knowledge_centers/integrated-circuit/ic-types/processors/tensor-processing-unit-tpu/ and the above-listed Open Titan first party silicon, but these are not general purpose system on a chip (SOC). Of course even Google has the rumor mill swirling on occasion with stories like "Whitechapel" https://www.theverge.com/2020/4/14/21221062/google-processor-pixels-chromebooks-whitechapel-samsung-qualcomm, too.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So how does the OS impact the firmware? Well, since the firmware is closely tied to the overall platform and hardware design, OS 'requirements' documents http://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf and https://source.android.com/compatibility/10/android-10-cdd can dictate some of these choices. And even for more open firmware implementations like Chromebooks you can see the coupling https://www.chromium.org/chromium-os/2014-firmware-summit.
