linux-kernel - Re: [PATCH v3 2/3] x86/signal: Rewire the restart

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 09:32:23 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Pedro Alves <palves@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, Kees Cook <keescook@...omium.org>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Re: [PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to
 have a constant nr

On Jun 21, 2016 5:40 AM, "Pedro Alves" <palves@...hat.com> wrote:
>
> Hi Andy,
>
> On 06/21/2016 12:39 AM, Andy Lutomirski wrote:
> > Suppose a 64-bit task A traces a 32-bit task B.
>
> I gave your x86/ptrace branch a try:
>
>  https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/ptrace
>
> (this looks to be the same patch set.)
>
> Unfortunately, with gdb git master, I still get the
> 64-bit ptracer x 32-bit ptracee problem:
>
>  (gdb) r
>  Starting program: interrupt.32
>  talk to me baby
>  ^C

I didn't try that particular experiment.  But, from that email:

> After that, GDB can control the stopped inferior. To call function "func1()" of inferior, GDB need: Step 1, save current values of registers ($rax 0xfffffffffffffe00(64 bits -512) is cut to 0xfffffe00(32 bits -512) because inferior is a 32 bits program).

That sounds like it may be a gdb bug.  Why does gdb truncate the register?

I haven't played with it recently, but, in my experience, gdb seems to
work quite poorly in mixed-mode situations.  For example, if you
attach 64-bit gdb to qemu-system-x86_64's gdbserver, boot a 64-bit
guest, and breakpoint in early 32-bit code, gdb tends to explode
pretty badly.

On x86_64, I think gdb should treat CPU state as 64-bit no matter
what.  The fact that a 32-bit tracee code segment is in use shouldn't
change much.

Admittedly the kernel doesn't really help.  There is some questionable
code involving which regsets to show to ptrace.