ASUS KGPE-D16 Dasharo testing update


Software testing is very important in every type of project to ensure the quality reaches the desired level and the product is in a production state. Unlike software testing, firmware testing does not only verify whether the code behaves as it is supposed to, but also covers functional verification if the hardware works as it should. It makes firmware validation much harder than any software application as we may face many unexpected and not always reproducible issues. The firmware industry constantly tries to improve itself in the field of validation and quality assurance, so is Dasharo. This time we made a huge leap in ASUS KGPE-D16 testing.

New tests

One may check the testing results for each release in the spreadsheet. We have added a bunch of new tests which were conducted on the most recent v0.3.0 release binary (yes, the tests have been repeated on the same binary). The new tests have the 23.03.2022 date appended in the header.

The scope has been extended with the following tests:

Verified boot

The basic tests conducted earlier simply checked if vboot is enabled and the platform boots. It missed the verification of real vboot functionality. So the tests have been extended to check whether vboot selects firmware partition A to boot from. It tells us whether vboot verified the firmware correctly and it has not been tampered with. Additionally, we have simulated the attack on firmware partition A by modifying it inside the flash. In such a case vboot should detect tampering with the firmware and request recovery mode. Unfortunately, it does not happen, the platform is stuck in a boot loop unable to request the recovery mode. The issue has been described here

Platform suspend resume

Our validation also covers testing of the ACPI S3 suspend/resume. The platform performs 30 cycles of suspend and resume to OS from RAM. ACPI S3 resume follows a slightly different boot path than normal boot and different issues may be detected in the process. Fortunately, the platform passes the test without issues.

Flash Write protection

Our KGPE-D16 setups contain DIP8 to SOIC8 flash adapters with a header for WP pin jumper. It allows us to set a write protection range and lock it by shorting the WP pin with a jumper. Our tests automate the process of setting the protected ranges. However, the configuration with W25Q128FV 16MB flash failed the test probably due to a missing or buggy implementation of the write protection for this particular chip in flashrom. The issue has been described here. The W25Q64FV 8MB flash works well. Locking the flash part allows creating a Static Root of Trust.

Measuring boot time

coreboot has a built-in mechanism to gather timestamps from the platform initialization steps and calculate the booting time. Our test automates the process of extracting those timestamps/measurements and calculates the total booting time. These values are pretty high right now (25s) since the serial console debug output is enabled. The BMC also takes a few seconds to be detected as non-functional (our setups do not have the BMC firmware module).


In total, we have increased the number of conducted tests by 16 (8 on each platform setup) of which 12 passed and 4 failed. Specifications of these have also been prepared which may always be found on the Dasharo documentation page.

If you think we can help in improving the security of your firmware or you looking for someone who can boost your product by leveraging advanced features of the used hardware platform, feel free to book a call with us or drop us email to contact<at>3mdeb<dot>com. If you are interested in similar content feel free to sign up to our newsletter

Michał Żygowski
Firmware Engineer with networking background. Feels comfortable with low-level development using C/C++ and assembly. Interested in advanced hardware features, security and coreboot. Core developer of coreboot. Maintainer of Braswell SoC, PC Engines, Protectli and Libretrend platforms.