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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 14 Apr 2013 21:12:05 +0200
From:	Oleg Nesterov <>
To:	Andrew Morton <>
Cc:	Alan Stern <>,
	Frederic Weisbecker <>,
	Ingo Molnar <>,
	Jan Kratochvil <>,
	Maneesh Soni <>,
	Prasad <>,
Subject: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()


On top of "[PATCH 0/5] kill ptrace_{get,put}_breakpoints()".
Cleanup and preparation for the potential fix, see below.

Now the question. Initially I was going to make more patches
and fix the regression introduced by 24f1e32c (although I am
not 100% sure which exactly patch should be blamed).

See for

ptrace_write_dr7() does not create bp if it is zero, the comment

	 * We should have at least an inactive breakpoint at
	 * this slot. It means the user is writing dr7 without
	 * having written the address register first.
and this looks logical. However, at least until 72f674d2
ptrace_set_debugreg(n => 7) worked even if addr wasn't set
by ptrace_set_debugreg(n => 0|1|2|3) before.

And note that ptrace_get_debugreg() does not fail if !ptrace_bps[n],
it just returns zero as if the address register was written. And
there is no way to know if address was actually set, not good and
not consistent.

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.

	2. Change ptrace_get_debugreg(0-4) to return -ESOMETHING if
	   ptrace_bps[n] == NULL.

	   This will match ptrace_set_debugreg(), but this can break
	   something else...

	3. Do nothing.

I am inclined to do "1", but please comment.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists