lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 14 Apr 2008 22:21:39 +0200
From:	Christian Schmidt <lkml@...add.de>
To:	linux-kernel@...r.kernel.org
Subject: ptrace (PTRACE_GETREGS, ...) discrepancy for x86 emulation on x86_64?

Hi all,

I'm currently toying around a bit with the ptrace api on linux. First, a 
few specs:

Kernel 2.6.24.4, glibc 2.7, x86_64 arch.

I am using the 32bit emulation on this to debug a program "the old way", 
putting "int3" opcodes into the code via PTRACE_POKE and waiting for the 
trap. In theory, I should than use PTRACE_GETREGS, decrement the EIP 
register, restore the original opcode, write the registers back with 
PTRACE_SETREGS, and the program should continue.
What I see instead is that regs.eip if 0xffffffff, and the next register 
contains the expected code offset.

I wonder if the reason is:

/usr/src/linux-2.6.24.4/include/asm-x86/ptrace.h:

struct pt_regs {
         long ebx;
         long ecx;
         long edx;
         long esi;
         long edi;
         long ebp;
         long eax;
         int  xds;
         int  xes;
         int  xfs;
         /* int  xgs; */
         long orig_eax;
         long eip;
         int  xcs;
         long eflags;
         long esp;
         int  xss;
};

/usr/src/linux-2.6.24.4/arch/x86/ia32/ptrace32.c:

static int putreg32(struct task_struct *child, unsigned regno, u32 val)
{
         int i;
         __u64 *stack = (__u64 *)task_pt_regs(child);

         switch (regno) {
         case offsetof(struct user32, regs.fs):
                 if (val && (val & 3) != 3) return -EIO;
                 child->thread.fsindex = val & 0xffff;
                 break;
         case offsetof(struct user32, regs.gs):
                 if (val && (val & 3) != 3) return -EIO;
                 child->thread.gsindex = val & 0xffff;
                 break;

So GS is still set (somewhere), though not defined for userspace. Am I 
correct, and should I fix my includes? After uncommenting the "int xgs;" 
above the program works.

Regards,
Chris

PS: I'm not subscribed, direct CC: to me is appreciated
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ