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  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:	Sun, 14 Apr 2013 21:40:49 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Maneesh Soni <maneesh@...ux.vnet.ibm.com>,
	Prasad <prasad@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()

On 04/14, Jan Kratochvil wrote:
>
> On Sun, 14 Apr 2013 21:12:05 +0200, Oleg Nesterov wrote:
> > Jan, Frederic, et all. What do you think we should do?
> >
> > 	1. Change ptrace_write_dr7() to do register_user_hw_breakpoint()
> > 	   if necessary.
> >
> > 	   This is what I was going to do, but I am no longer sure
> > 	   we want this. For what? Unlikely it is very useful to use
> > 	   the "default" addr == 0 for debugging.
>
> I do not understand how these functions map to the PTRACE_* syscall.
>
> But this was a regression from the application point of view as some
> application did/do:
> 	* waitpid - get the process to: t (tracing stop)
> 	* PTRACE_POKEUSER DR7, enableDR0
> 	* PTRACE_POKEUSER DR0, address
> 	* PTRACE_CONT
>
> This was perfectly valid before, there is no "default" addr == 0 used for any
> debugging.  Just the applications did not care about PTRACE_POKEUSER ordering.
> This is also how the bug was found.

Yes, exactly.

Except 'there is no "default" addr == 0', the first
"PTRACE_POKEUSER DR7, enableDR0" used addr == 0 and then it was
changed by "PTRACE_POKEUSER DR0".

And once again, I am ready to make the patch, it should be simple.
Just I am not sure it worth the trouble, so I decided to ask first.
Nobody noticed this problem(?) except you, and this was broken a
long ago.

	PTRACE_POKEUSER DR0, address
	PTRACE_POKEUSER DR7, enableDR0

should work and this looks better, we do not enable bp until it
has the correct address set.  Of course this doesn't really matter
if the tracee doesn't not run in between, but still...

Oleg.

--
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