From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BcpDs-0000E4-6x for qemu-devel@nongnu.org; Tue, 22 Jun 2004 13:38:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BcpDq-0000DJ-8G for qemu-devel@nongnu.org; Tue, 22 Jun 2004 13:38:14 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BcpDq-0000Cm-6K for qemu-devel@nongnu.org; Tue, 22 Jun 2004 13:38:14 -0400 Received: from [213.146.130.142] (helo=trantor.org.uk) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BcpC8-0006FZ-53 for qemu-devel@nongnu.org; Tue, 22 Jun 2004 13:36:28 -0400 Subject: Re: [Qemu-devel] BIOS checksums? From: Gianni Tedesco In-Reply-To: <20040621221005.40221.qmail@web60201.mail.yahoo.com> References: <20040621221005.40221.qmail@web60201.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7Wp8zRW7XVpyDLATZbVJ" Date: Tue, 22 Jun 2004 18:35:53 +0100 Message-Id: <1087925753.30448.15.camel@sherbert> Mime-Version: 1.0 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --=-7Wp8zRW7XVpyDLATZbVJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-06-21 at 15:10 -0700, Piotr Krysik wrote: > Hi, >=20 > A few words about the architecture. >=20 > As I mentioned, I'm trying to use QEMU to monitor > interactions between guest OS and real hardware. >=20 > 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 >=20 > 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. >=20 > I'm emulating some of the protected IO ports. With you. > 2. Memory >=20 > 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. >=20 > 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 >=20 > 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:-) >=20 > I'm protecting real CPU from switching A20 and reset, > and redirect them to emulated CPU. >=20 > 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. >=20 > 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. >=20 > 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. --=20 // 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 --=-7Wp8zRW7XVpyDLATZbVJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA2G34kbV2aYZGvn0RAm4SAJ920J2C4Be06JBQdHk1SqMhM5Q37gCfSWTt y+jD1zSNJmPxa7hdDpW4oZs= =CYYD -----END PGP SIGNATURE----- --=-7Wp8zRW7XVpyDLATZbVJ--