Unifying x86 segment register support for kernel debugging

[Julian Kirsch <kirschju at sec dot in dot tum dot de>]

Hi all,

as a follow-up on the patch adding the fs_ and  gs_base pseudo registers
to gdb's i386:x86-64 architecture (see Richard Henderson's patch [0]) I
would like to address the following issue:

While most OSs use fs_ and gs_base in some predefined manner (linux -
tls/windows - SEH, PPEB), gdb provides no way of obtaining base
addresses of other selectors. The generic solution to this would be to
add the gdtr register to gdb's core registers and then let the user
derive the base address (plus other information, if needed) from the gdt
entry referenced by a certain selector (using a script or manually).
This approach, however has several problems:

  - There is (at least to my knowledge) no way of obtaining the gdtr
    of the cpu the tracee is running on using ptrace. One would have to
    modify the ptrace syscall in the kernel to add a means of returning
    the gdtr of the traced process or come up with some other trick.
  - Neither the fs_/gs_base nor the gdtr are accessible when tracing
    x86 processes.
  - Last but not least it is of course much more convenient to just
    be able to read the fs_/gs_base pseudo registers directly from
    gdb's output rather than doing to lookup in the GDT manually each
    time or hand-crafting a script to do it automatically. I understand
    that the status quo is the "easy" solution to get the values of
    interest, my only concern is that it's not a very generic solution.

However, the gdbserver built into qemu _does_ have access to the gdtr
and accordingly could easily send this information to a remote gdb
client. As the gdtr (and the idtr) are of special interest during kernel
debugging (linux and windows, certainly for other OSs as well) in 32-
and 64-bit mode, I'd therefore suggest to add two new architectures
i386:x86:qemu and i386:x86-64:qemu that additionally/instead include the
gdtr and the idtr register.

There is a patch ready that adds fs_base and gs_base to qemu's 'g'
packet for 64 and 32 bit guests (the latter of course breaks
compatibility to gdb with the patch [0]) that I wrote. I would,
nevertheless, for the reasons explained above, like to discuss the idea
of adding a new architecture specifically targeting qemu's gdbserver
rather than artificially complicating the current architecture and
breaking backwards compatibility for 32 bit tracees/qemu guests ("Remote
packet for 'g' is too long").

Additionally, in my opinion it would make sense to have access to (some
of) the MSRs of a qemu guest using gdb. This could also be taken care of
when introducing new "qemu" pseudo target architectures and would be the
clean solution compared to messing any further with standard x86/x86-64.

I'd be happy to take care of creating the two new architectures at the
gdb and the qemu side, but I'd first like to check whether there is
interest in such a feature and/or if I made a stupid mistake in any of
my assumptions/conclusions. What do you think?


Best,
Julian

[0] https://sourceware.org/ml/gdb-patches/2015-11/msg00078.html