[SeaBIOS] Problems with Linux payload

Kevin O'Connor kevin at koconnor.net
Thu Aug 28 01:14:51 CEST 2014


On Wed, Aug 27, 2014 at 02:17:55PM -0700, Curt Brune wrote:
> Just before executing that instruction the CPU registers look like
> this (from the qemu monitor):
> 
>   (qemu) info registers
>   EAX=00000018 EBX=1ffd6610 ECX=00000000 EDX=00000000
>   ESI=00090000 EDI=00090334 EBP=00040070 ESP=00006fa4
>   EIP=01000014 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>   ES =0018 000f0000 0000ffff 00009b00 DPL=0 CS16 [-RA]
>   CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
>   SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   DS =0018 000f0000 0000ffff 00009b00 DPL=0 CS16 [-RA]
>   FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>   TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy

Those segment descriptors (see CS16, CS32 above) look like they're
using the SeaBIOS gdt.  So, it looks like something is trying to
change segments without having properly invoked the "lgdt"
instruction.

[...]
> Just before executing the troublesome instruction @ 0x1000014 the CPU
> registers look like this (from the qemu monitor) in the working case:
> 
>   (qemu) info registers
>   EAX=00000018 EBX=1ffd6610 ECX=00000000 EDX=00000000
>   ESI=00090000 EDI=00090334 EBP=00127ff0 ESP=1ffd0f88
>   EIP=01000014 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>   ES =0018 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
>   SS =0018 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   DS =0018 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   FS =0018 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   GS =0018 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>   TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy

In the above you see "DS" and "CS32" describing those descriptors.
So, either a "lgdt" instruction was issued in this case, or a gdt was
already present that just happened to be compatible with the above
code.

> Here the interesting thing is that DS, ES and SS *already* contained
> 0x18.  In the SeaBIOS case those registers contained 0x10 before the
> Linux kernel set them up.
> 
> That's all I got.  Any clues?

Sounds like either Linux, or whatever tool you used to generate the
linux payload is at fault.  Armed with the above, I'd ask on the
coreboot mailing list.

-Kevin



More information about the SeaBIOS mailing list