As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):
https://firmwaresecurity.com/2016/04/20/windows-smm-security-mitigations-table/
The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]
Full spec:
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
http://www.uefi.org/acpi
Also, there’s a strange copyright in this spec:
Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.
Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).
In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:
MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
…/WindowsSmmSecurityMitigationTable.h | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
+#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATURE SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)
Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:
[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.
For full patch, see list archives:
https://lists.01.org/mailman/listinfo/edk2-devel