Skip to content

Instantly share code, notes, and snippets.

@benjamindoron

benjamindoron/gsoc2021_minplatformboard.md

Last active August 23, 2021 18:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save benjamindoron/cf9ce28bba0b6356113918a40814af30 to your computer and use it in GitHub Desktop.
Save benjamindoron/cf9ce28bba0b6356113918a40814af30 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gsoc2021_minplatformboard.md

GSoC 2021 project - MinPlatform board port

Acer Aspire VN7-572G

Overview

I successfully ported MinPlatform to the specified Acer Skylake platform. It boots an operating system successfully, with some additional platform features enabled. In general, the port as-is could be suitable for daily use, with some caveats relating to security and platform/board feature enablement. I use and performed my testing with Fedora 34, with no relevant modifications.

This board was a good candidate for the project because it has Boot Guard disabled (but it's also the only x86 system that I own, so it's the only board I could choose). While I wasn't aware of this when I purchased this laptop, those planning/willing to port open-source firmware to their boards should know that this is important. Better yet, if the Management Engine is unfused (still in manufacturing mode), users may be able to take advantage of these features themselves.

Note: AMD has equivalent technologies, but I'm less informed about their PSP and Platform Secure Boot. Additionally, as I understand and at the time of writing, their support for open-source firmware is less well-developed.

Unfortunately, this board does not seem readily available for purchase anymore, but these efforts improved common code and future porting efforts. I hope that this project serves as a good example of a board port and encourages others to develop ports as well, making open-source firmware more widely available.

Compared to my previous work developing a coreboot port for this board, more time went into improving the EC feature support, including initialisation and event notification functions, detecting board SKU and hardening the firmware for security.

Comparing MinPlatform and coreboot, my experience is that MinPlatform's support for and ease of integration of UEFI-specific features is obviously superior, compared to coreboot with UefiPayload. In contrast, coreboot has some user-friendly features presently missing in MinPlatform: writing an ACPI _ROM method for dGPU drivers in OS, and a fallback mechanism which allows testing potentially breaking changes in a separate 'partition.'

Of course, much of the above is just my opinion and based on my understanding (which may be incorrect).

Work performed

The primary work-product for this project is the following patchset (v3):

I also made some miscellaneous bugfixes and improvements to common platform code. The below have been merged:

These patches have not yet been merged:

Additionally, my project proposal mentioned that debug logging might be performed using the StatusCode infrastructure. This was insufficient for my purposes, as the in-memory handler does not capture full debug logs, only a binary bitmask indicating progress. These can be thought of as being similar to postcodes on port 0x80.

Therefore, I developed a set of libraries for EDK2, which write debug output from the PEI, DXE and SMM phases to an in-memory ringbuffer. At the end of boot, the address and size of this buffer are written to EFI variables for the user's convenience. These libraries have not yet been upstreamed, partly due to a bug that I want to fix first in the PEI library instance/copying the buffer thereof and partly because writing data to memory in SMM phase requires more consideration for security, despite the validation checks we already perform. I plan to fix these bugs and upstream the libraries. Until then, they can be found at my edk2 fork, presently this commit.

Challenges

  • On cache-as-RAM teardown: Structures are migrated, but some pointers might not be updated. The debug library stack I was using for early testing (PeiSerialPortLibSpiFlash, very helpful for early debugging) contained a pointer in a HOB, so debug output was stopping at CAR teardown. Due to a separate issue, the system wasn't booting, so this looked like a very broken build, possibly a bug in FSP TempRamExit() - this was not the case. Such causes should be considered for issues at this stage.
  • Failure to issue global reset: This was less difficult to root-cause. FSP requests a global reset ("FSP_STATUS_RESET_REQUIRED_3") if it power-gates SoC devices. This can happen if the device is enabled in the policy but not detected (due to GPIO, PMC registers, I'm not sure). Presently, the solution is to pass the correct policy to FSP, but once global resets are implemented, not doing so won't be fatal to the build.

After these challenges were addressed, the system booted an operating system successfully for the first time.

Replication

  • Consider enabling USE_PEI_SPI_LOGGING and/or USE_MEMORY_LOGGING in OpenBoardPkg.dsc.
  • Build an image.
  • Flashing externally: The SPI flash chip is near the fan, at the center of the board. The keyboard must be removed first. I use a Raspberry Pi with a SOIC-8 test clip.
  • Flashing internally: At least one external flash is required (or find an exploit against the outdated vendor firmware to unlock the flash). I recommend hex-editing the IFR of the vendor's SetupUtility module to display the "BIOS SPI Lock" option. This way, flashing internally between firmware is possible ("i-Page" is also interesting, it allows enabling "Advanced" and "Power" pages with most of the silicon configuration).
    • Intel FPT (Flash Programming Tool) can be used in the UEFI shell if booting an OS fails.
    • flashrom can be used in a Linux distribution.
    • Intel FPT can be used in Linux and also in Windows.
  • Recovering logs:
    • USE_PEI_SPI_LOGGING: Read the SPI flash and extract the first padding section (consider UEFITool).
    • USE_MEMORY_LOGGING: List EFI variables and read "DebugLogsAddress" and "DebugLogsCursor" or "DebugLogsSize." Dump system memory from "DebugLogsAddress" until "DebugLogsCursor" or "DebugLogsSize" to a file. In Linux, the dd tool can be used with "/dev/mem" as the input.

Caveats/Work for the future

Security

  • The flash chip storing the firmware image was left writable for my convenience while testing and debugging images. This is not production-ready. I plan to add support for configuring locking in the setup menu in the future. Regardless, users should consider their threat model and see the lines mentioning PchLockDown or LockDownConfig in the PeiBoardPolicyUpdate.c files.
  • NX (no-execute), or XD (execute-disable), is a security technology that can mitigate exploitation by preventing buffer overflows from enabling code execution. Although presently disabled on all/most platforms, I attempted to enable it but was then unable to boot. A debug log would be required to find the issue, but I was unable to acquire one.

Broken platform features

  • FSP Dispatch mode: Anticipated not working until either MinPlatform implements global reset, or the required policy entries can be exposed so that FSP does not request a global reset.
  • S3: This is mostly straightforward, but broken somewhere. An uncorrupted debug log could not be obtained at this time. At least one possible bug is known: do not pass a GraphicsConfigPtr to FSP-S on S3 resume.

Enabling advanced features

  • ACPI debug modules install duplicate ACPI table, producing a conflict. Reviewing the code will determine whether dropping the duplicate function call of the callback is sufficient.
  • User authentication DXE module has a duplicate, so there are two menus created. Reviewing the code will determine whether dropping the duplicate module is sufficient.

Improving board features

  • Support for handling some EC events is present already, but this can be improved. By further reverse-engineering the vendor firmware, I plan to add support for handling more EC events called by ACPI and SMM.
  • Aspire VN7-792G: Support has not yet been added for this similar board. By performing binary-diffing and reverse-engineering the differences between the SKU's vendor firmware, I hope to add support in the future. Relevant logs from interested users could be very helpful.
    • As that board has a PCH-H instead of PCH-LP, PCB routing is anticipated to be different. Therefore, support for VN7-792G is considered to be completely broken and could even cause short-circuits. At this time, users are strongly advised against flashing to this board!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment