From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128689 invoked by alias); 13 Nov 2015 20:17:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 128679 invoked by uid 89); 13 Nov 2015 20:17:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: mail-out1.informatik.tu-muenchen.de Received: from mail-out1.informatik.tu-muenchen.de (HELO mail-out1.informatik.tu-muenchen.de) (131.159.0.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 13 Nov 2015 20:17:34 +0000 Received: from [192.168.1.7] (x4d045e53.dyn.telefonica.de [77.4.94.83]) by services.sec.in.tum.de (Postfix) with ESMTPSA id 4972A10AEA809 for ; Fri, 13 Nov 2015 21:17:31 +0100 (CET) Message-ID: <5646455A.1010603@sec.in.tum.de> Date: Fri, 13 Nov 2015 20:17:00 -0000 From: Julian Kirsch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Unifying x86 segment register support for kernel debugging Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00025.txt.bz2 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