Dear everyone,
For my master project I will apply hardening techniques (sanitizers/CFI) to System Mangement Mode (SMM). Now for my evaluation, I want to test code in SMM and ideally cover all SMI handlers coreboot offers. However, in my experience, System Management Interrupts (SMIs) rarely trigger and the variety in SMIs is also rather low (testing via QEMU). I was wondering whether anyone is familiar with testing such a low-level component. In the coreboot repository, I couldn't find any tests related to SMM and looking online also hasn't provided me any answers.
Is there anyone who has experience with similar problems or can perhaps point me into the right direction, as I am inexperienced with testing such low-level components.
I hope I've explained myself clearly, if not, please indicate so!
Kind regards,
Mick
Mick wrote:
For my master project I will apply hardening techniques (sanitizers/CFI) to System Mangement Mode (SMM).
Cool! And ambitious. :)
Now for my evaluation, I want to test code in SMM and ideally cover all SMI handlers coreboot offers.
Keep in mind that SMM code isn't common for all of coreboot, it can and will be both board-specific and platform-specific.
However, in my experience, System Management Interrupts (SMIs) rarely trigger and the variety in SMIs is also rather low (testing via QEMU).
In general coreboot makes an attempt to not go overboard with SMM code, in particular the QEMU board code may have almost none, to the point where it's far from representative for modern platforms.
Some platforms depend heavily on SMM (e.g. virtual PCI devices) others less so.
I was wondering whether anyone is familiar with testing such a low-level component.
In general I'd advise you to prepare a hardware environment for this task, and make sure that you have CPU-level debug access. An older AMD APU board is probably the easiest target, unless your university already has the 100k¤-stuff :( for modern platform hardware debug. Or perhaps you can find an industry partner.
Is there anyone who has experience with similar problems
I think the project is both novel and worthwhile, unfortunately that means you're probably also fairly alone...
The good news is that you'll find far-above-average SMM experience in the coreboot community. :)
//Peter
Hello Peter,
Thank you for your response!
Cool! And ambitious. :)
Yeah, the project is pretty hacky, to be frank, and will be limited to the setup where SMRAM is from a0000h to bffffh.
In general coreboot makes an attempt to not go overboard with SMM code, in particular the QEMU board code may have almost none, to the point where it's far from representative for modern platforms.
Yes, I'm aware of coreboot's stance on SMM. If I recall correctly, QEMU seemed to have trouble clearing the SMI_STS register. We will likely use hardware to test the setup. You're confirming my fear related to testing SMM in QEMU. I hope we will be able to see more SMM activity on a real board, but I don't know what to expect, as I have trouble finding sources that discuss how SMM is used in the "wild" (besides articles on reversing and exploiting SMM).
Are you aware whether SMM is tested (for new functionality, for instance), and if so, how that is being done? Or is this done by using existing hardware setups? I do not have a lot of experience with low-level hardware.
Thanks for your input :).
Kind regards,
Mick
samcrowmk@gmail.com wrote:
Yeah, the project is pretty hacky, to be frank, and will be limited to the setup where SMRAM is from a0000h to bffffh.
That still covers lots of real hardware.
Yes, I'm aware of coreboot's stance on SMM. If I recall correctly, QEMU seemed to have trouble clearing the SMI_STS register.
There's not much reason for QEMU to use SMM, so it may not have a full or even working emulation.
We will likely use hardware to test the setup. You're confirming my fear related to testing SMM in QEMU. I hope we will be able to see more SMM activity on a real board, but I don't know what to expect, as I have trouble finding sources that discuss how SMM is used in the "wild" (besides articles on reversing and exploiting SMM).
I think you'll find (much) more SMM activity on hardware. A few examples:
* Legacy keyboard controller emulation for USB keyboards by BIOS You can verify this by letting the BIOS boot some program that never uses interrupts to interact with the keyboard, but exclusively direct IO around port 60h, and perhaps interrupt 1.
* "VSA" on Geode platforms emulate entire PCI devices using SMM.
* Look for SMM usage in ACPI, especially common for embedded controllers in laptops.
Are you aware whether SMM is tested (for new functionality, for instance), and if so, how that is being done? Or is this done by using existing hardware setups? I do not have a lot of experience with low-level hardware.
To firmware developers, coreboot at least, I would argue that SMM is seen mostly as a neccessary evil, both because it's cumbersome to deal with, because it interferes with a "clean" system and because it's a matter of fact over which firmware developers have no control.
Platform vendors' hardware design decisions drive the SMM requirements for firmware, seemingly with increasing tendency over time.
//Peter
Hi Peter,
Pardon me for the late response, at the moment I have an apu2e2 board [1] which I'm trying to set up. The configuration uses the following file for the Southbridge SMI handlers: src/southbridge/amd/pi/hudson/smihandler.c [2]. The amount of SMI code in it is quite small, in comparison to the SMM code for Intel CPUs in src/southbridge/intel/ [3], for example.
Nevertheless, I would be able to perform testing on this board, I think. Do you have pointers as to how I could increase the code present in SMM, or is this simply the configuration for the board and that's that? Thank you for your help thus far.
Best regards,
Mick
[1] https://www.pcengines.ch/apu2.htm [2] https://github.com/pcengines/coreboot/blob/f658838fbb91a428dd46887e49a02a066... [3] https://github.com/pcengines/coreboot/blob/f658838fbb91a428dd46887e49a02a066...
-
Mick -
Peter Stuge -
samcrowmk＠gmail.com