Re: [Qemu-devel] BIOS checksums?

Re: [Qemu-devel] BIOS checksums?

[Piotr Krysik]

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

Hi,
 
Are you talking about using proprietary closed-source BIOS-es of real PC? They are usually very hardware-depended.
 
In fact I started a project to use QEMU to monitor interactions between guest OS and real hardware (similar to "PCI Host/Proxy" by Gianni Tedesco, but not limited to PCI hardware). At this point I have prof of concept prototype that successfully boots proprietary BIOS of my PC up to the point of testing the RAM.
 

Regards,
 
Piotrek


Hetz Ben Hamo <hetz@witch.dyndns.org> wrote:
Hi,

Since Fabrice opened the possibility to replace BIOSes, I decided to 
play a bit with few of them on QEMU.

All of them seems to return one problem - Checksum error. I tried some 
Phoenix BIOSes, Award, MR. Bios - all with the same problem (some just 
giving a ROM checksum error messages, other simply doesn't show anything)

All the BIOSes I tried are from the boards who supported pentium pro..

Have anyone had better luck? I'll be happy to provide links to some 
BIOSes (all from their vendors)

Thanks,
Hetz


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

[-- Attachment #2: Type: text/html, Size: 1711 bytes --]

Re: [Qemu-devel] BIOS checksums?

[Gianni Tedesco]

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

On Mon, 2004-06-21 at 07:29 -0700, Piotr Krysik wrote:
> Are you talking about using proprietary closed-source BIOS-es of real
> PC? They are usually very hardware-depended.
>  
> In fact I started a project to use QEMU to monitor interactions
> between guest OS and real hardware (similar to "PCI Host/Proxy" by
> Gianni Tedesco, but not limited to PCI hardware). At this point I have
> prof of concept prototype that successfully boots proprietary BIOS of
> my PC up to the point of testing the RAM.

Sounds very interesting, are you doing this just generically by just
hooking up virtual i/o ports to real ones? I guess to get a BIOS running
it takes more than that?

Doesn't the BIOS use the PMC config space to query DRAM bank layout? If
so that shouldn't be too difficult to modify hw/pci.c to do the right
thing(tm)....

-- 
// 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 --]

[Qemu-devel] BIOS checksums?

[Hetz Ben Hamo]

Hi,

Since Fabrice opened the possibility to replace BIOSes, I decided to 
play a bit with few of them on QEMU.

All of them seems to return one problem - Checksum error. I tried some 
Phoenix BIOSes, Award, MR. Bios - all with the same problem (some just 
giving a ROM checksum error messages, other simply doesn't show anything)

All the BIOSes I tried are from the boards who supported pentium pro..

Have anyone had better luck? I'll be happy to provide links to some 
BIOSes (all from their vendors)

Thanks,
Hetz

Re: [Qemu-devel] BIOS checksums?

[Piotr Krysik]

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.


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.


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.

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.


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.


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.


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


Regards,

Piotrek

--- Gianni Tedesco <gianni@scaramanga.co.uk> wrote:
> On Mon, 2004-06-21 at 07:29 -0700, Piotr Krysik
> wrote:
> > Are you talking about using proprietary
> closed-source BIOS-es of real
> > PC? They are usually very hardware-depended.
> >  
> > In fact I started a project to use QEMU to monitor
> interactions
> > between guest OS and real hardware (similar to
> "PCI Host/Proxy" by
> > Gianni Tedesco, but not limited to PCI hardware).
> At this point I have
> > prof of concept prototype that successfully boots
> proprietary BIOS of
> > my PC up to the point of testing the RAM.
> 
> Sounds very interesting, are you doing this just
> generically by just
> hooking up virtual i/o ports to real ones? I guess
> to get a BIOS running
> it takes more than that?
> 
> Doesn't the BIOS use the PMC config space to query
> DRAM bank layout? If
> so that shouldn't be too difficult to modify
> hw/pci.c to do the right
> thing(tm)....
> 
> -- 
> // 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 part 1.2 application/pgp-signature
name=signature.asc
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: [Qemu-devel] BIOS checksums?

[Gianni Tedesco]

[-- 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 --]

Re: [Qemu-devel] BIOS checksums?

[Piotr Krysik]

--- Gianni Tedesco <gianni@scaramanga.co.uk> wrote:
> On Mon, 2004-06-21 at 15:10 -0700, Piotr Krysik
> wrote:
> > 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...

It should be possible to modify op_raise_interrupt to
handle int15/e820 as a special case for emulated CPU.
I didn't implement it yet. For my Linux exercise with
Bochs BIOS I just modified CMOS-stored memory size.
BIOS did the rest:-)


> > 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?

Yes.

In QEMU, the emulated CPU does direct access only to
memory registered with cpu_register_physical_memory.
The rest of CPU address space is handled by
unassigned_mem_read/unassigned_mem_write functions
(with exception of regions registered with
cpu_register_io_memory).

For the prototype I register RAM area allocated to
guest OS with cpu_register_physical_memory(0,
guest_ram_size, 0). The rest of CPU address space is
handled by unassigned_mem_read/unassigned_mem_write.
In these functions I forward memory access to the real
machine (after checking that it doesn't overlap with
the emulator).


> So when do we see the patches? ;))

At this point it's just quick and dirty prototype not
ready for public release. And I don't expect to reach
release quality any time soon. As it matures I'd like
to release it under GPL (it depends only on libqemu,
so I'm not limited to GPL).


> > 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.

Yes. And I had to intercept and emulate these
registers, because at the point BIOS started
reprogramming PMC I lost control over emulator.


Regards,

Piotrek



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail