[ipxe-devel] any details about the state of KEEP_IT_REAL?

[Michael Brown]

On Tuesday 12 Jun 2012 14:15:34 Klaus Espenlaub wrote:
> > In the many years since I first implemented KEEP_IT_REAL, this is the
> > first time that anyone has expressed any substantial interest in it.  I
> > have personally never come across a deployment product that requires
> > KEEP_IT_REAL.  Even the most internally convoluted (Tivoli, which uses
> > VM86 mode and ring 1) manages to work with iPXE as-is.
> 
> Interesting and strange at the same time - anything using VM86 can't use
> the normal code sequence for switching back to protected mode
> (real_to_prot).

Tivoli's VMM goes to incredible lengths to emulate real mode.  It intercepts 
and interprets our GDT and CR0 changes, and ends up dropping us into protected 
mode in ring 1 (rather than ring 0) with a GDT that matches our expectations 
for segment register values.  iPXE's existing real_to_prot and prot_to_real 
continue to work even inside the VMM.

Given the extraordinary effort that the VMM goes to, it's almost sad to observe 
that it leaves us with a GDT that still provides unrestricted access to the 
whole 4GB address space.  There is therefore nothing that actually prevents us 
from overwriting the real GDT and breaking out to ring 0.
 
> This is only relevant for the case where the OS which was booted through
> PXE wants to continue using PXE services (such as UNDI). Generally there
> is a workaround (using the actual NIC driver instead of the generic one
> using UNDI), but that's very ugly.

Only DOS does that, as far as I am aware, and that should work as long as 
EMM386 is disabled.

> > Resurrecting support should be reasonably straightforward.
> 
> That's good to know. We'll probably look into this. From a first peek
> it's not that much work. The biggest problem seems "bit rot" in
> i386-kir.lds, which uses different symbol names and lacks a significant
> number of symbols referenced by the rest of iPXE. Of course always
> keeping fingers crossed that the relocation nagging by the linker is
> mostly harmless (or due to exceeding the 64K size limit).

There has been quite a lot of restructuring in i386.lds since KEEP_IT_REAL was 
last touched, including fixes for some really obscure bugs in various binutils 
versions.  I would strongly recommend ditching i386-kir.lds and generating a 
new version: use i386.lds as the template and adapt it to fit the section 
layout of the old i386-kir.lds.

Michael