Re: [Qemu-devel] BIOS checksums?

[Gianni Tedesco <gianni@scaramanga.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 4337 bytes --]

On Mon, 2004-06-21 at 15:10 -0700, Piotr Krysik wrote:
> Hi,
> 
> A few words about the architecture.
> 
> As I mentioned, I'm trying to use QEMU to monitor
> interactions between guest OS and real hardware.
> 
> To avoid interactions between guest and host OS, I
> decided to run QEMU _without_ OS. It's started by boot
> loader. The QEMU log is send to another machine. The
> other machine can also be used to run remote gdb.

Nice approach :)

> 1. IO
> 
> QEMU uses serial port to communicate with the other
> machine. There are also some other ports that should
> be protected from access by code executed in the
> emulator, as they may interact with QEMU (e.g. CPU
> reset, DRAM Controller reprogramming). All the other
> emulated IO ports are hooked to real machine.
> 
> I'm emulating some of the protected IO ports.

With you.

> 2. Memory
> 
> I have to reserve some memory for QEMU. I'm allocating
> some MB of top of RAM. The rest is visible to guest OS
> with it's real address (addresses used by emulated CPU
> is identical to addresses used by hardware), so it
> should be possible to use DMA without translating
> addresses. Also I don't have to treat memory mapped
> hardware in any special way.

How is e820 map obtained, would it be possible to intercept that to
setup a new reserved area I wonder? ;)

An uglier approach would be adding to the e820 map which is presumably
stored in the ROM, and fixup the checksum...

I wonder if this patch could be made to live inside the qemu tree,
sounds invasive?

> The QEMU area is not visible to emulated CPU, so it's
> protected from direct access by guest OS. It could be
> accessed by DMA (e.g. broken drivers). If such
> (unlikely) case is discovered, it can be handled by
> intercepting and modifying IO or memory access used to
> setup that DMA.
> 
> To run BIOS, I had to intercept some IO that tried to
> reprogram RAM Controller.

Is this because of the way you reserve RAM?

> 3. CPU
> 
> QEMU runs in real mode with 32-bit addressing. All the
> interrupts are redirected from host hardware to QEMU
> by IRQ handler calling cpu_interrupt. Guest OS uses
> emulated CPU provided by QEMU:-)
> 
> I'm protecting real CPU from switching A20 and reset,
> and redirect them to emulated CPU.
> 
> To run BIOS, I had to disable SMM (System Management
> Mode) by reprogramming ACPI, emulate self-test of
> Keyboard Controller and intercept IO access to ACPI
> and an unknown device at 0x03fX.

sounds like deep dark stuff, but potentially very useful for reverse
engineering purposes such as is needed to create free BIOSes.

> After QEMU is started it's possible to:
>   * reset some hardware and restart BIOS or
>   * reload boot sector and start guest OS.
> 
> It's not possible to build generic emulator capable of
> restating BIOS. My prototype runs 440BX-based PC with
> Award-based BIOS. The BIOS successfully reprograms
> emulated DRAM Controller, test interrupts, initializes
> PCI, etc. It's stating to test RAM and then goes into
> BIOS setup (I didn't discover the reason yet, but
> suspect timing). Emulating BIOS restart can be used to
> monitor interactions between BIOS and hardware during
> system start-up. And the mechanism is not limited to
> PC.
> 
> Reloading boot sector and starting guest OS without
> restarting BIOS should remove most of chipset and BIOS
> dependencies. My prototype is capable to run Linux up
> to the point of login prompt, but keyboard is not
> functioning (my interrupt handler is not 100%
> correct). This mode was tested only with QEMU emulated
> hardware -- I run Linux inside my prototype inside
> QEMU inside Linux.

So when do we see the patches? ;))

> BTW. What is "PMC config space"? Did you mean DIMM
> Serial Presence Detect?

In the PCI configuration space of the PCI controller itself (0:0.0) are
contained registers such as:

 DRAM Row Type
 DRAM Control
 DRAM Timing
 DRAM Row Boundary
 Fixed DRAM Hole Control
 SMRAM Control

But as I see now, these values are programmed in to the PMC by the BIOS,
duh.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]