Hi, I would like to implement a piece of code as an SMM handler in LinuxBIOS.
From what I understand of LinuxBIOS, there is no SMM handler at present
but the SMM registers on the AMD K8 platform are locked using the SMMLOCK bit. How does the platform then handle SMI when using LinuxBIOS? I would be grateful for any advice or gotchas for my implementation.
Thanks, Arvind
On 12/24/06, Arvind Seshadri arvinds+@cs.cmu.edu wrote:
Hi, I would like to implement a piece of code as an SMM handler in LinuxBIOS.
I think the sensible way to do this is write an SMI handler that is controlled by Linux (or other OS). BIOS code should not run once the OS is up. There are lots of OS-dependent issues that a BIOS just can not know about. To pick a simple example: Are you going to ensure that your SMI handler is SMP-safe? If so, how, and for which OS? I know of one vendor BIOS (EFI on the LLNL Thunder cluster, an itanium-based machine, from several years ago) that was not re-entrant or SMP-safe, and it was not fun when two CPUs tried to enter this BIOS at once.
Once the OS is up, the CPU should always be under control of the OS. So, build an SMI handler for linux -- if you really need to do this.
ron
I would like to implement a piece of code as an SMM handler in LinuxBIOS.
I think the sensible way to do this is write an SMI handler that is controlled by Linux (or other OS). BIOS code should not run once the OS is up.
But SMM code isn't BIOS code -- it is "virtual hardware".
There are lots of OS-dependent issues that a BIOS just can not know about. To pick a simple example: Are you going to ensure that your SMI handler is SMP-safe? If so, how, and for which OS?
SMM is not reentrant, and the SMM hardware takes care of that (modulo some hardware bugs, heh). The SMM code has to go to great pains to ensure following the proper ordering rules for the real and the virtual hardware (most implementations fail miserably here) -- this is really hard to do, the whole SMM concept is such a bad design.
I know of one vendor BIOS (EFI on the LLNL Thunder cluster, an itanium-based machine, from several years ago) that was not re-entrant or SMP-safe, and it was not fun when two CPUs tried to enter this BIOS at once.
Fun eh.
Once the OS is up, the CPU should always be under control of the OS. So, build an SMI handler for linux -- if you really need to do this.
If you're going to implement SMM in the OS, you can just as well simply implement the necessary code in some device drivers. Much easier.
Segher
I was going to say the same thing: SMM code is meant to the OS independent since it emulates hardware functionality. But I agree with the requirement for the code being reentrant since the trend is towards multicore CPUs.
BTW, I was looking over the datasheet for the AMD8111 southbridge and found that several sources can generate an SMI. There are enable bits for the individual SMI sources as well as a global SMI enable/disable bit. Given that LinuxBIOS does not currently handle SMI, where is SMI disabled in the code? I did some grepping around in the code and could not find anything for the AMD K8. Is it the case that SMI is disabled after reset and has to explicitly enabled by the BIOS?
Arvind
On Fri, 29 Dec 2006, Segher Boessenkool wrote:
I would like to implement a piece of code as an SMM handler in LinuxBIOS.
I think the sensible way to do this is write an SMI handler that is controlled by Linux (or other OS). BIOS code should not run once the OS is up.
But SMM code isn't BIOS code -- it is "virtual hardware".
There are lots of OS-dependent issues that a BIOS just can not know about. To pick a simple example: Are you going to ensure that your SMI handler is SMP-safe? If so, how, and for which OS?
SMM is not reentrant, and the SMM hardware takes care of that (modulo some hardware bugs, heh). The SMM code has to go to great pains to ensure following the proper ordering rules for the real and the virtual hardware (most implementations fail miserably here) -- this is really hard to do, the whole SMM concept is such a bad design.
I know of one vendor BIOS (EFI on the LLNL Thunder cluster, an itanium-based machine, from several years ago) that was not re-entrant or SMP-safe, and it was not fun when two CPUs tried to enter this BIOS at once.
Fun eh.
Once the OS is up, the CPU should always be under control of the OS. So, build an SMI handler for linux -- if you really need to do this.
If you're going to implement SMM in the OS, you can just as well simply implement the necessary code in some device drivers. Much easier.
Segher
* Arvind Seshadri arvinds+@cs.cmu.edu [061230 05:13]:
BTW, I was looking over the datasheet for the AMD8111 southbridge and found that several sources can generate an SMI. There are enable bits for the individual SMI sources as well as a global SMI enable/disable bit. Given that LinuxBIOS does not currently handle SMI, where is SMI disabled in the code? I did some grepping around in the code and could not find anything for the AMD K8. Is it the case that SMI is disabled after reset and has to explicitly enabled by the BIOS?
Global SMI Control Register (PM2C) is initialized with 00, thus disabling all SMI activity in the system. If you want to change this, you need to create an SMM handler, and set those bits you need, for example in the Global SMI Enable Register (PM2A)
Unless you do, no SMIs will happen, and that situation is locked to avoid malware messing with SMI.
One question: why are you going to need SMI? USB legacy emulation?
Stefan
Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my purpose very well. I am working on a project called Pioneer, whose goal is to prevent any malware present on a computer from tampering with code execution (details can be found at http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html). I would like to implement the Pioneer code as an SMI handler to prevent an attacker from using the SMI as an attack vector. My current plan is to generate an SMI to all CPUs on the system via an IPI. Since all SMI sources on the Southbridge as well as CPU local SMI sources seem to be disabled on a system with LinuxBIOS, I do not have to worry about catching SMIs from any sources other than mine.
Thanks to you guys for an open source BIOS that makes my life a lot easier! I was wondering how on the earth I was going to reverse engineer a proprietary SMM handler to get my code to play nicely...
Best wishes, Arvind
On Tue, 9 Jan 2007, Stefan Reinauer wrote:
- Arvind Seshadri arvinds+@cs.cmu.edu [061230 05:13]:
BTW, I was looking over the datasheet for the AMD8111 southbridge and found that several sources can generate an SMI. There are enable bits for the individual SMI sources as well as a global SMI enable/disable bit. Given that LinuxBIOS does not currently handle SMI, where is SMI disabled in the code? I did some grepping around in the code and could not find anything for the AMD K8. Is it the case that SMI is disabled after reset and has to explicitly enabled by the BIOS?
Global SMI Control Register (PM2C) is initialized with 00, thus disabling all SMI activity in the system. If you want to change this, you need to create an SMM handler, and set those bits you need, for example in the Global SMI Enable Register (PM2A)
Unless you do, no SMIs will happen, and that situation is locked to avoid malware messing with SMI.
One question: why are you going to need SMI? USB legacy emulation?
Stefan
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/
Hi Arvind,
Arvind Seshadri wrote:
Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my purpose very well. I am working on a project called Pioneer, whose goal is to prevent any malware present on a computer from tampering with code execution (details can be found at http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html).
It seems you are simply reimplementing SEBOS in a more complicated way. See http://www.missl.cs.umd.edu/sebos.html for details.
Regards, Carl-Daniel
Hi Carl-Daniel, SEBOS is based on AEGIS, which is a secure bootstrap mechanism. As such, SEBOS can only guarantee the integrity of what programs are loaded into memory. This property is similar to that provided by the TCG trusted boot specification and is called loadtime attestation.
Loadtime attestation does not guarantee that a program which is loaded into memory and checked for integrity is what gets executed. The program can be modified by the attacker before being invoked for execution. For example, an attacker can overwrite memory locations in the program via a DMA write. Also, both AEGIS and the TCG specification depend on HW modifications and cannot be used by legacy systems.
Pioneer provides the stronger guarantee that the program whose integrity is checked is the one that is invoked for execution. In other words, an attacker cannot modify the program between the time its integrity is checked and the time the program is invoked for execution. Also, where as AEGIS and TCG only measure programs loaded at system boot, Pioneer can measure and launch programs at any point in time. The property provided by Pioneer is, therefore, similar to the late-launch capability of Intel's LT and AMD's SVM, which can be used to design systems with substantially smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM however, Pioneer is completely software-based and can be used on legacy systems.
Cheers, Arvind
On Thu, 11 Jan 2007, Carl-Daniel Hailfinger wrote:
Hi Arvind,
Arvind Seshadri wrote:
Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my purpose very well. I am working on a project called Pioneer, whose goal is to prevent any malware present on a computer from tampering with code execution (details can be found at http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html).
It seems you are simply reimplementing SEBOS in a more complicated way. See http://www.missl.cs.umd.edu/sebos.html for details.
Regards, Carl-Daniel -- http://www.hailfinger.org/
Hi Arvind,
Arvind Seshadri wrote:
Pioneer provides the stronger guarantee that the program whose integrity is checked is the one that is invoked for execution. In other words, an attacker cannot modify the program between the time its integrity is checked and the time the program is invoked for execution. Also, where as
But an attacker can modify the program directly after its execution has started. So Pioneer secures exactly one machine instruction more than SEBOS. I don't think that this is impressive. With current hardware it is impossible (except if you use an IOMMU) to guarantee that a program is not modified during execution. I hope I didn't discuorage you and am still very interested in the results of Pioneer.
AEGIS and TCG only measure programs loaded at system boot, Pioneer can measure and launch programs at any point in time. The property provided by Pioneer is, therefore, similar to the late-launch capability of Intel's LT and AMD's SVM, which can be used to design systems with substantially smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM however, Pioneer is completely software-based and can be used on legacy systems.
Only on legacy systems with LinuxBIOS or on all legacy systems?
Regards, Carl-Daniel
Hi Carl-Daniel, Having an IOMMU is not necessary since our goal is only to prevent DMA write to a region of memory. We have come up with techniques that can prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is not LinuxBIOS-specific. It can be incorporated into any SMM code.
Cheers, Arvind
On Fri, 12 Jan 2007, Carl-Daniel Hailfinger wrote:
Hi Arvind,
Arvind Seshadri wrote:
Pioneer provides the stronger guarantee that the program whose integrity is checked is the one that is invoked for execution. In other words, an attacker cannot modify the program between the time its integrity is checked and the time the program is invoked for execution. Also, where as
But an attacker can modify the program directly after its execution has started. So Pioneer secures exactly one machine instruction more than SEBOS. I don't think that this is impressive. With current hardware it is impossible (except if you use an IOMMU) to guarantee that a program is not modified during execution. I hope I didn't discuorage you and am still very interested in the results of Pioneer.
AEGIS and TCG only measure programs loaded at system boot, Pioneer can measure and launch programs at any point in time. The property provided by Pioneer is, therefore, similar to the late-launch capability of Intel's LT and AMD's SVM, which can be used to design systems with substantially smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM however, Pioneer is completely software-based and can be used on legacy systems.
Only on legacy systems with LinuxBIOS or on all legacy systems?
Regards, Carl-Daniel
Hi Arvind,
Arvind Seshadri wrote:
Having an IOMMU is not necessary since our goal is only to prevent DMA write to a region of memory. We have come up with techniques that can prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is
That sounds interesting. Are you using the GART present in most current systems?
not LinuxBIOS-specific. It can be incorporated into any SMM code.
Thanks for clarifying that.
Regards, Carl-Daniel
Hi Carl-Daniel, Yep, the GART is one way to go. On the other hand, there are PCI-Express systems that do not have a GART. The whole thing is a bit of a mess, which is why I didn't expand on it.
Cheers, Arvind
On Fri, 12 Jan 2007, Carl-Daniel Hailfinger wrote:
Hi Arvind,
Arvind Seshadri wrote:
Having an IOMMU is not necessary since our goal is only to prevent DMA write to a region of memory. We have come up with techniques that can prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is
That sounds interesting. Are you using the GART present in most current systems?
not LinuxBIOS-specific. It can be incorporated into any SMM code.
Thanks for clarifying that.
Regards, Carl-Daniel -- http://www.hailfinger.org/
-
Arvind Seshadri -
Carl-Daniel Hailfinger -
ron minnich -
Segher Boessenkool -
Stefan Reinauer