On Wed, Feb 5, 2014 at 8:08 AM, Ramkumar Ramachandra email@example.com:
I'm currently researching the SMM mode, and would appreciate pointers on what the code in src/cpu/x86/smm does.
- It seems to me that smi_handler() is executed everytime there's an
SMI interrupt. When does this occur? How can I inspect what exactly happens when an SMI is fired? Also, what is smm_handler_start(), and when is it executed?
- Isn't the firmware supposed to write thermal and power data to
SMRAM while in SMM mode? Where is the code for this?
- Is smm_setup_relocation_handler() called when the SMBASE is
relocated? I see comments in smmrelocate.S justifying why SMBASE needs to be relocated from the default value. What does the Intel manual have to say about this (I'm reading Chapter 34 from 3C)?
- How does coreboot ensure that SMRAM isn't accessible from a non-SMM
mode? Various papers talk about D_LOCK and D_OPEN registers; where are these registers set?
- How does Linux interact with software that is executed in SMM mode,
if at all? I could only find one reference to SMM in the codebase: Documentation/dcdbas.txt; it talks about a Dell Systems Management Base Driver.
Although I can't speak to your exact questions, here is a general response:
Coreboot's SMI handler is designed primarily for compatible operation. It is a no-frills approach to what the SMI handler must do, and does not include any extras (D_LOCK and D_OPEN are extras). It only has to do just barely enough so the OS kernel can load and the OS kernel will then take care of any higher level tasks such as thermal and power monitoring.
That means the SMRAM is not protected, which makes sense since the only "threat" to SMRAM would be a rogue OS kernel.
Linux probably doesn't interact with the SMI handler at all.