[gPXE-devel] [PATCH] [romprefix] Consider PCI3 init-time segment in BIOS area insane

Joshua Oreman oremanj at mit.edu
Thu May 27 04:30:42 EDT 2010


On Thu, May 27, 2010 at 1:15 AM, Michael Brown <mbrown at fensystems.co.uk> wrote:
> On Thursday 27 May 2010 07:55:36 Joshua Oreman wrote:
>> [I'm not sure if the generalization here is correct, and I don't have
>> access to the PCI3 specification. Could someone with more PCI
>> knowledge comment? --Josh]
>>
>> At least one BIOS invokes the gPXE ROM with %cs = 0xCE00 (a perfectly
>> valid runtime segment) and %gs = 0xE000 (a very dangerous runtime
>> segment). The proper action in response to this bug is to not relocate
>> to %gs, just as we would if %gs were outside the BIOS area or the
>> runtime and init-time segments overlapped. The init-time segment should
>> always be in conventional memory for a compliant PCI3 system.
>
> PCI 3.0 spec states:
>
>  "POST Firmware will place the Expansion ROM in RAM at an address that may
>   not be the final run-time execution address. This address will be below the
>   1-MB address boundary."
>
> and also
>
>  "Prior versions of the PCI Specifications have described the address where
>   Expansion ROMs will be placed as typically being from 0C0000h up to
>   0E0000h. This version of the specification now expands that region to be
>   from A0000h to FFFFFh inclusively. The PCI 3.0 compliant system firmware
>   will place the PCI 3.0 compliant Expansion ROM code at any aligned address
>   within this expanded range."
>
> so technically {init=0xce00,runtime=0xe000} is a valid combination, though
> unusual.
>
> Which BIOS does this?  Does it actually fail if we relocate to 0xe000?  Is the
> segment at 0xe000 writable at init-time?  (If the runtime segment is non-
> writable, that might be a suitable test to use instead.)

This was reported by Kyle Kienapfel on #etherboot today, on a system
with a Phoenix Award BIOS ("the motherboard from an Acer Aspire E700
crammed into an old case"). He was getting a banner of

    03:03.0 CE00 PCI3.00 PnP BBS PMM0043 at 08 EC00

and a freeze with two gibberish characters printed immediately after
the POST-time prompt. This failure mode suggests to me that we did
write something to EC00; if we hadn't, it seems there shouldn't have
been a problem until the actual BEV execution. the A test with iPXE's
PMM enhancements worked:

    03:02.0 CE00 PCI3.00 PnP BBS PMM+0042D600+0043B4E0 E000

though I suspect that was only randomly by virtue of the different
runtime address. With gPXE + this patch we got

    03:02.0 CE00 PCI3.00!DE00 PnP BBS PMM0043 at 08 CE00

which also worked.

I'm not sure why the runtime address was different each time, but I
don't know of any system where 0xe0000 and up are not mapped to [a
shadowed copy of] the system BIOS.

-- Josh

>
> Michael
>


More information about the gPXE-devel mailing list