On Mon, Jul 30, 2007 at 01:46:33PM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
>> Hi,
>> i decided to do some cheating :) and skipped the breakpoint where it used
>> to
>> stop (0x40200). (by the way, hitting 'c' wouldn't continue at all and keep
>> executing the same instruction over and over again). This time it seems it
>> behaves as expected:
>
> Uhm, it looks to me that you ran qemu with the -kernel option again (I can
> tell because the dump exhibits a few bugs that are characteristic of the
> qemu loader.) This makes qemu itself load the kernel and not rely on the
> boot loader that's on your bootloader.
>
> I was expecting you to run "qemu -S -s -hda /dev/hda -snapshot", which you
> previously said when run (without the -S -s) options reproduced the
> problem.
ups, sorry for that, i thought falsely here that you want to debug the kernel
part of the setup code ...
>
> After taking the dump, please do:
>
> delete
> c
>
> ... to verify the problem is reproduced.
In this case, we never land on a jump instruction:
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in ?? ()
(gdb) set arch i8086
The target architecture is assumed to be i8086
(gdb) disp/i ($cs << 4)+$eip
1: x/i ($cs << 4) + $eip 0xffff0: ljmp $0xf000,$0xe05b
(gdb) br *0x10200
Breakpoint 1 at 0x10200
(gdb) br *0x20200
Breakpoint 2 at 0x20200
(gdb) br *0x30200
Breakpoint 3 at 0x30200
(gdb) br *0x40200
Breakpoint 4 at 0x40200
(gdb) br *0x50200
Breakpoint 5 at 0x50200
(gdb) br *0x60200
Breakpoint 6 at 0x60200
(gdb) br *0x70200
Breakpoint 7 at 0x70200
(gdb) br *0x80200
Breakpoint 8 at 0x80200
(gdb) br *0x90200
Breakpoint 9 at 0x90200
(gdb) c
Continuing.
Breakpoint 4, 0x00040200 in ?? ()
1: x/i ($cs << 4) + $eip 0x40300: lea (%si),%dx
(gdb) c
Continuing.
if i do delete here, it loads the second stage of grub and continues to load the
kernel. Is there another way to land at the jmp instruction instead of poking
blindly, maybe disassemble something parts of the initial code. \me reading
grub-docs...
--
Regards/Gru?,
Boris.
Borislav Petkov wrote:
>
> if i do delete here, it loads the second stage of grub and continues to load the
> kernel. Is there another way to land at the jmp instruction instead of poking
> blindly, maybe disassemble something parts of the initial code. \me reading
> grub-docs...
>
Oh lovely. The purpose of this was to intercept the running of the
kernel setup code. If grub doesn't load it at a 64K boundary, it is
hard to guess what it would do.
I'll do some experiments with qemu here and see if I can figure out a
way to get it to trap at the right point.
-hpa
Borislav Petkov wrote:
>
> Breakpoint 4, 0x00040200 in ?? ()
> 1: x/i ($cs << 4) + $eip 0x40300: lea (%si),%dx
> (gdb) c
> Continuing.
>
> if i do delete here, it loads the second stage of grub and continues to load the
> kernel. Is there another way to land at the jmp instruction instead of poking
> blindly, maybe disassemble something parts of the initial code. \me reading
> grub-docs...
>
If you do "delete" without a breakpoint number, you're deleting all
breakpoints. I just experimented with grub, and it looks like it should
break at 0x90200, so just set that breakpoint and none of the others.
-hpa
On Wed, Aug 01, 2007 at 10:36:07AM -0400, H. Peter Anvin wrote:
> Borislav Petkov wrote:
>> Breakpoint 4, 0x00040200 in ?? ()
>> 1: x/i ($cs << 4) + $eip 0x40300: lea (%si),%dx
>> (gdb) c
>> Continuing.
>> if i do delete here, it loads the second stage of grub and continues to
>> load the
>> kernel. Is there another way to land at the jmp instruction instead of
>> poking
>> blindly, maybe disassemble something parts of the initial code. \me
>> reading
>> grub-docs...
>
> If you do "delete" without a breakpoint number, you're deleting all
> breakpoints. I just experimented with grub, and it looks like it should
> break at 0x90200, so just set that breakpoint and none of the others.
>
> -hpa
Hi,
now this is one of those cases where one tries to shoot a small fly with a
nuclear missile. The first assumption that something was wrong with the kernel
setup code was wrong and here's how i know:
The problem with my version of grub not hitting the breakpoint 0x90200 made me
think that something might be messed up in the grub part of the boot sequence.
Thus, i did the qemu simulation again and noticed on the initial boot screen of
grub it saying "Grub version 0.91." However, you remember from a different post
that the version of grub i have is the latest to be found in debian unstable,
0.97-29, so i thought that something has to be wrong with it and especially with all
those grub stages binaries, in my case in /boot/grub, which grub-install setups.
Checking their timestamps revealed that the files are from 2004 so i thought,
well, these are OLD! :) After refreshing the grub installation and replacing
the stages-binaries with the fresh ones, the kernel booted just fine :), here:
[boris@gollum:07:02:07:~:9994)-> uname -a
Linux gollum 2.6.22-4fd06960f120e02e9abc802a09f9511c400042a5-12 #12 PREEMPT Thu Jul 26 18:08:34 CEST 2007 i686 GNU/Linux
so i guess the problem was with the ancient parts of a grub installation i had
lying around which weren't replaced by the apt-get update process and somehow
messed up newer grub versions. Anyway, in the end one still learns a lot while at it.
Thanks for your help.
--
Regards/Gru?,
Boris.
Borislav Petkov wrote:
>
> Hi,
>
> now this is one of those cases where one tries to shoot a small fly with a
> nuclear missile. The first assumption that something was wrong with the kernel
> setup code was wrong and here's how i know:
>
> The problem with my version of grub not hitting the breakpoint 0x90200 made me
> think that something might be messed up in the grub part of the boot sequence.
> Thus, i did the qemu simulation again and noticed on the initial boot screen of
> grub it saying "Grub version 0.91." However, you remember from a different post
> that the version of grub i have is the latest to be found in debian unstable,
> 0.97-29, so i thought that something has to be wrong with it and especially with all
> those grub stages binaries, in my case in /boot/grub, which grub-install setups.
> Checking their timestamps revealed that the files are from 2004 so i thought,
> well, these are OLD! :) After refreshing the grub installation and replacing
> the stages-binaries with the fresh ones, the kernel booted just fine :), here:
>
> [boris@gollum:07:02:07:~:9994)-> uname -a
> Linux gollum 2.6.22-4fd06960f120e02e9abc802a09f9511c400042a5-12 #12 PREEMPT Thu Jul 26 18:08:34 CEST 2007 i686 GNU/Linux
>
> so i guess the problem was with the ancient parts of a grub installation i had
> lying around which weren't replaced by the apt-get update process and somehow
> messed up newer grub versions. Anyway, in the end one still learns a lot while at it.
>
> Thanks for your help.
>
Very cool. I actually suspected that, but I wanted to explore all
avenues. I'm glad this can be written off.
-hpa