.png){kind=small}
Introduction
We are happy to announce the simultaneous release of Dasharo firmware v1.1.7 for MSI PRO Z690-A and v0.9.5 for MSI PRO Z790-P. The full changelogs are available in the Dasharo documentation:
Both releases share the same set of changes and bring noteworthy new features, most prominently the preliminary SMI Transfer Monitor (STM) support and the new Platform Setup Menu with experimental CPU overclocking options. Let’s walk through what’s new.
Preliminary SMI Transfer Monitor (STM) Support
One of the most significant additions in this release is the preliminary support for SMI Transfer Monitor (STM). STM is a hypervisor-like component that runs in System Management Mode (SMM) and provides isolation and protection of SMM code from potentially malicious OS or hypervisor code. By placing a monitor between the OS/hypervisor and the SMM environment, STM helps enforce the security boundaries that SMM relies on.
This is a foundational step toward a more robust and trustworthy firmware security architecture. We mark it as preliminary as we continue to validate and mature the implementation across our supported platforms.
See how to verify the STM works
here. It requires
recompiling kvm modules and compiling dual_monitor_mode out-of-tree module.
The process is not user-friendly, but we are planning to make it more
automated and easy to use.
What a deeper dive into STM, SMM security issues it addresses, etc. please refer to this paper. More about STM can also be found on Intel page.
Huge kudos to:
- Brian Delgado from Intel, who inspired us to integrate STM on the MSI desktops
- Eugene D. Myers for contributing STM support to coreboot and developing STM PE and contributing fixes to original STM repository
- Jiewen Yao from Intel, the author of STM
- Peter Tsung Ho Wu for contributing fixes to original STM repository
STM bugs in coreboot
Since the introduction of STM support in coreboot (beginning of 2020) there has been essentially no activity in STM development, except two fixes for:
That fact has caused a lot of issues when attempting to launch STM for the first time:
- STM build for coreboot without serial console does not work
- STM build for coreboot may not be reproducible
- STM page faults with coreboot
- STM fails to validate BIOS resources
- coreboot does not describe all resources to STM
Before integrating the STM in our releases, those had to be addressed first. Let’s go through each of them to see what it took to fix the problems. Set of fixes may be found here.
STM build for coreboot without serial console does not work
The problem here was a bit ambiguous. It resulted from the fact that:
- coreboot did not describe all resources to STM yet (including cbmem console address).
- coreboot did not provide proper page tables causing STM to page fault.
- The STM sources did not allow to disable serial port. If
UARTparameter was not provided, it was forcefully set to0x3f8, meaning the serial console is always enabled, even if coreboot setSTM_TTYS0_BASEto0x000.
The fix was to set UART to some unused I/O
port,
like 0xf0, describe all resources used by SMM properly, and construct page
tables for STM. Without those fixes, the STM setup simply froze the OS, when
loading dual_monitor_mode kernel module.
STM build for coreboot may not be reproducible
As in the title, coreboot did not use its own (cross)compiler to build STM, instead relied on host compiler. To fix this, we have changed the CMake parameters to pass the right compiler.
STM page faults with coreboot
Another cause of a frozen OS when attempting to launch an STM was a page fault when the STM tried to access the VMCS structure:
|
|
The cause is of course bad page tables. When placing STM in MSEG (monitor
segment) memory, coreboot has to prepare page tables for STM too. Those page
tables covered only the first 4GB of address space, so any pointer to memory
above 4GB would result in page-fault, e.g. 10AE47000 pointing to VMCS. The
fix was simply to create page tables for the whole address
space
indicated by CPU physical address bits in CPUID.
STM fails to validate BIOS resources
When launching the STM, a couple of lines indicated a problem with the BIOS resource list:
|
|
The reason for this was the mismatch of header files between coreboot and STM sources causing the structure sizes to be different. This was likely caused by this commit. I had to revert it to fix the sizes of BIOS resource structures. With that in place, STM no longer complained on invalid resource list.
coreboot does not describe all resources to STM
This was the most challenging issue to solve. Since there are many SMI handlers with various purposes, it is hard to check all possible resources that the SMI handler may try to access. But the most obvious ones are as follows:
- Power Management Controller (PMC) I/O (ACPI) and MMIO registers, for power transitions in SMI sleep handlers
- P2SB (Primary to Sideband) registers space (some SMI handlers may need it)
- SPI flash resources (SPI MMIO), flash memory mapped address, SMMSTORE communication buffers
- cbmem regions needed to be accessed by SMI handlers (TPM PPI ACPI NVS, console)
- any other hardware, like serial port if SMI debugging is enabled
This commit generally adds a more complete list of BIOS resources needed by SMI handlers. It includes the PMC, P2SB, SPI, TXT registers spaces, serial port (both I/O and MMIO), PCI I/O ports, SPI controller PCI configuration space. We have also added a mainboard hook for mainboards that use their own specific resources in mainboard SMI handlers.
The trickiest part was the SPI flash access in SMM with SMMSTORE, because:
- SPI controller PCI configuration space is needed to get SPI MMIO BAR, so has to be described in resource list.
- SPI MMIO BAR has to be fixed (STM is loaded before PCI enumeration) and passed in the BIOS resource list
- SMMSTORE communication buffer has to hold both the SPI flash block data and parameters. Previously the caller could allocate buffer with parameters (command, block number, etc.) in an arbitrary location, which caused EPT violation in STM. Increasing the SMM communication buffer by one page to put the parameters there, fixed the problem.
- SMMSTORE communication buffer had to be passed in resource list.
- TXT MMIO space had to be passed in resource list because SMM BIOS Write Protection (BWP) SMI handler accesses these registers to properly support the feature.
- Special chipset usage MSR had to be passed in resource list, because it is used by SMM BWP and EISS (Enable InSMM.STS) features in SMI handlers.
- SMI handlers that modify SMM save state area have to set a hint bit in SMM
descriptor.
SMI handlers like SMMSTORE modify the SMM save state area on CPU to
convey the operation status to the caller via the architectural registers,
such as EAX/RAX. Any SMI handler that does so, must set the
SmramToVmcsRestoreRequiredfield in the SMM descriptor, otherwise the updates to SMM save state area are discarded.
This only shows how complex the security is on our PCs. If even one resource was missing, the STM would yield an EPT violation and the SMM handler would be denied access to a given resource and fails its execution. Example of SMMSTORE write operation failing due to reallocated SPI MMIO address:
|
|
Or the SMMSTORE SMI handler parameters passed outside of SMMSTORE communication buffer:
|
|
STM bugs conclusion
Since this is preliminary support for STM in Dasharo, not all issues may have been identified yet. If you notice any weird behavior when STM is enabled, do not hesitate to report it to us.
New Platform Setup Menu
This release introduces a new Platform Setup Menu accessible from the Device Manager in the firmware setup. The menu currently offers two sets of experimental options:
Experimental CPU/Overclocking Options
Warning: These options are experimental. Incorrect settings may cause system instability, or hardware damage. Use them at your own risk.
For a long time, members of the Dasharo community and Dasharo Pro Package owners have been requesting access to CPU and overclocking controls in the firmware setup. We have heard you loud and clear - some of these options are now available in the Platform Setup Menu on MSI PRO Z690-A and Z790-P boards.
However, we want to be transparent about what this means in practice. The community’s enthusiasm is well-founded, but the expectation is equally clear: these options need to be tested thoroughly, and results, documentation, and tuning guides need to be developed by the community. Most of the options are simply passed to the Intel FSP silicon initialization module. It may happen that in certain circumstances the change in option value may have no effect due to unknown dependencies between FSP options. Dasharo does not provide support for these overclocking options, and users who change these settings take full responsibility for any instability or damage that may result from doing so.
We look forward to seeing the community experimenting with these options and sharing their findings, documentation, and guides - that is the spirit that makes Dasharo great.
Experimental RAM Voltage Configuration (DDR4)
Also under the Platform Setup Menu, DDR4 variant users will find experimental controls for RAM voltage configuration. As with the CPU overclocking options, these are experimental and unsupported - proceed with care.
Warning: Modifying RAM voltage can damage memory modules. Changes are made entirely at the user’s own risk.
SBOM Embedded into Firmware
The Software Bill of Materials (SBOM) is now embedded directly into the firmware image, making it easier to verify the provenance of firmware components. For this release, the SBOM includes:
- coreboot 25.12 (rev c96f0b7a)
- EDKII edk2-stable202602 (rev 5dc2238e)
- Intel FSP RPL-S C.0.C8.50
- Intel ME v16.1.30.2307
- Intel microcode: ADL/RPL C0/H0 0x3e, RPL B0 0x137
Intel microcode has been luckily updated to the most recent release from August 11th to provide the latest security and bug fixes.
MRC Cache Preserved Across Capsule Updates
Memory Reference Code (MRC) cache is now preserved during capsule firmware updates. Previously a capsule update would invalidate the MRC cache, forcing a full memory training on first boot after the update. This change noticeably reduces the time spent on the first boot following a firmware update.
EZ Debug LED Support
Support for EZ Debug LEDs has been added. These LEDs on MSI boards indicate which component is being initialized during POST, making hardware troubleshooting more straightforward.
Restoring Defaults via CMOS Battery Reset
Removing the CMOS battery will now correctly restore firmware settings to their defaults, as one would expect from standard PC behavior. Instead of reflashing the whole BIOS with MSI FlashBIOS due to a single option change causing a brick, it is now possible to restore defaults by resetting the CMOS battery.
TPM Single Active Bank Detection
Detection of TPMs that support only a single active PCR bank has been added. This prevents silent PCR bank change failures on systems with certain TPM configurations that cannot handle multiple simultaneous banks being active. If given TPM does not support multiple active PCR banks at once, an informational pop-up window is shown explaining the situation.
XMP Profile and Voltage Verification/Ramping (DDR4)
For DDR4 platforms, additional XMP-related logic has been added to verify and ramp voltage as part of XMP profile application, improving stability when enabling XMP profiles. Previously, the DRAM voltage was kept at its default 1.2V, while XMP profiles often request 1.35V or so. Now the XMP profile is parsed and verified if it is present, and if the requested voltage is different from default. If so, the new voltage is applied using DAC controllers present on the DDR4 board variants.
Changed
XMP Profile Selection Moved to Platform Setup Menu
XMP profile selection has been relocated from the Dasharo System Features menu to the new Platform Setup Menu, which provides a more logical grouping of memory and overclocking related options. See Platform Setup Menu
TPM Improvements
Several TPM-related changes have been made:
- SHA-1 and SHA-256 PCR extending is now performed for discrete TPMs (dTPM).
- The TPM event log no longer uses fixed-size entries, reducing wasted space.
- The TPM ACPI device path has been updated, which should improve Windows 11 compatibility with TPM-related features.
FreeBSD Compatibility Improvements
- MMX/SSE instructions have been removed from UEFI runtime drivers. This fixes
issues with
efivaron FreeBSD, which does not save/restore SSE state on EFI runtime calls. - The serial console is now registered after VGA initialization, resolving boot console issues on FreeBSD.
USB Port Power Disabled on Power Off
USB port power is now properly cut when the system powers off, which prevents devices from remaining powered when the system is shut down. This was observed by a community member and reported on Dasharo matrix space.
Fixed
Unable to Apply UEFI dbx Update via fwupdmgr
An issue that
prevented applying the UEFI Secure Boot Forbidden Signature Database (dbx)
update dated 2025-09-02 via fwupdmgr has been fixed by increasing the space
allocated for UEFI variables.
Cannot Enter Firmware Update Mode Twice in a Row
A bug where the system could not enter Firmware Update Mode a second time without a cold reboot in between has been resolved.
XMP3 Profile Shown on DDR4 Platforms
A cosmetic but confusing bug where the XMP profile selection option would show XMP profile 3 (which is a DDR5-only specification) on DDR4 platforms has been fixed. The option now correctly reflects DDR4 XMP profiles only.
Summary
This release marks meaningful progress on two important fronts: firmware security, with the preliminary SMI Transfer Monitor support, and user configurability, with the new Platform Setup Menu and its experimental CPU and RAM voltage options.
The experimental CPU overclocking options in particular reflect our commitment to listening to the community. We have received many requests from both community members and Dasharo Pro Package owners. With these options now available, the ball is in the community’s court to explore, test, document, and share tuning guides - the Dasharo team is watching with interest. Just remember: these options are unsupported and any hardware damage resulting from their use is the user’s responsibility.
We encourage everyone to update, test, and share your experiences through GitHub issues or Dasharo HCL reports via DTS.
If you’re looking for hardware with full Dasharo support, check out our Dasharo Supported Hardware.
Unlock the full potential of your hardware and secure your firmware with the
experts at 3mdeb! If you’re looking to boost your product’s performance and
protect it from potential security threats, our team is here to help.
Schedule a call with
us
or drop us an email at contact<at>3mdeb<dot>com to start unlocking the
hidden benefits of your hardware. And if you want to stay up-to-date on all
things firmware security and optimization, be sure to sign up for our
newsletter:
Also do not miss the Boot Security Mastery Conference (BSMConf) - a five-day event on September 21-25, 2026 in Gdańsk, Poland, combining hands-on training with technical talks on securing the platform boot chain.
