Re: How to generate a #SMI?
- From: Michael Tippach <spamtrap@xxxxxxxxxx>
- Date: Tue, 19 Sep 2006 22:49:37 +0200
Lighter wrote:
How to generate a #SMI?
The more important question would be: Once you know how to,
then what?
#SMI being pulled causes the chip set/CPU to open up the SMRAM
areas that are otherwise protected and the System BIOS would
have set the entry point to somewhere in there. Most of the
time, Non-SMM access to that area will be locked and not all
CPUs allow to revector the SMMBASE to an arbitrary address by
means as simple as writing to an MSR (as a rule of thump:
AMD do, Intel don't.)
Thus, short of exploiting common vulnerabilities that exist
in probably all BIOS implementations of an SMM handler, there
is no easy way of taking over control once you figured out how
to generate an SMI.
To my thinking, the current process can use I/O instructions to do
this. Say, the system provides a special I/O port; This port is an
interface of an actual device. Upon the device detectes signal at the
given port, it generates a #SMI.
Am I right?
Right on. There even is a compatible way to generate a software
SMI on any system that supports ACPI.
It comes down to finding the FACP (the ACPI spec has the
algorithm you would need to follow), a table that contains a port
address and a value to write to that port address in order for
an ACPI enabled OS to take over control.
There is another value that does the opposite and one for S4/BIOS,
which is obsolete. Either way, writing _any_ value to that port
will generate an SMI.
On Intel southbridges the software SMI port is always 0xB2, meaning
_any_ value written to that port will cause an SMI.
.
- References:
- How to generate a #SMI?
- From: Lighter
- How to generate a #SMI?
- Prev by Date: Re: Hex to ascii
- Next by Date: Having trouble posting?
- Previous by thread: Re: How to generate a #SMI?
- Next by thread: How to create a library that detects the processor and uses SIMD instructions as necessary
- Index(es):
Relevant Pages
|
