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>] [day] [month] [year] [list]
Message-Id: <4E9AE794-8227-4FA5-910A-5F612926A5AB@mathematik.uni-marburg.de>
Date:	Mon, 7 May 2012 15:03:46 +0200
From:	Christian Strack <strack@...hematik.Uni-Marburg.de>
To:	linux-kernel@...r.kernel.org
Subject: Debug Exception Handling in Linux

Hello,

I'm trying to single-step processes in  a HVM Linux guest using Xen on Intel VT. Especially i've changed the Ether patch for Xen to be able to handle Linux guests. My Problem is that every single step the RIP stored in the VMCS points to kernel instructions (>0xC0000000) and thus only kernel instructions are stepped. To achieve single-stepping, both the exception bitmap and the rflags are masked with the trap flag, debug register 6's 14th bit is set (single-stepping) and the exception is send to the guest using 

vmx_inject_hw_exception(v, TRAP_debug, VMX_DELIVER_NO_ERROR_CODE);

Has anybody a clue why the RIP points to kernel instructions or where the userland RIP is stored at this time? To avoid misunderstandings, i'm not searching for Xen specific answers. It would be very helpful if you could enlight me how the linux kernel handles debug exceptions or where the userland RIP is stored.

Kind regards
Christian

PS: Please add my address to CC

---
Ether patch: http://ether.gtisc.gatech.edu/source.html--
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