[BULK] [LinuxBIOS] elfboot() can trash GDT
Eric W. Biederman
ebiederman at lnxi.com
Thu Aug 4 09:47:41 CEST 2005
"Steve Magnani" <steve at digidescorp.com> writes:
> I've run into an interesting problem doing some "bait and switch" with my
> I have machine code for an x86 program that expects to run in protected
> mode. It's not an ELF file, so I can't load it directly with elfboot().
> What I'm doing for the time being is having elfboot load Etherboot, with
> the emulator set to break at the Etherboot entry address. When the
> breakpoint is hit I load the machine code into memory and change EIP to
> its entry point. (Ultimately I'll probably create an ELF wrapper for this
> code, but I don't have one yet).
> My machine code gets a protection exception when it tries to set one of
> the segment registers (to the value it already has, BTW). I traced this to
> the fact that Etherboot was loaded on top of the GDT used by LinuxBIOS.
Etherboot a few instructions later will load it's own GDT.
> We can argue about what kind of assumptions payloads should make about
> their runtime environment, but it seems to me that being in protected mode
> without a GDT is a bomb waiting to go off. Some payloads are bound to do
> things in a sequence that causes an explosion.
Not really. I don't think there are any processor operations that
automatically reload segment registers. In fact segment registers are
so useless that in 64bit mode they are not even implemented. If you want
to mess with the segment registers you should really be loading your own.
The values in the segments persist in the segment shadow registers. And
that is where the values matter. It is unfortunate that the registers
that matter are write only registers though.
> Can we move the GDT within the memory LB reports as unusable, say, before
> the tables?
I looked at the code and we aren't nuking the gdt deliberately. But
I am not really comfortable with applications caring about it. At one
point I was thinking it might be sane to return to LinuxBIOS but there
don't appear to be any uses for that.
The sane thing for an application to expect in 32bit protected mode
is flat 32bit segments with a base of 0. That is enough to get
things done. If you need something more I would like to hear why.
We really can't sanely fix this when you are doing something that
seems to have no real justification.
More information about the coreboot