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:	Mon, 5 Mar 2007 18:25:16 +0100
From:	Andi Kleen <ak@...e.de>
To:	eranian@....hp.com
Cc:	linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
	akpm@...ux-foundation.org, tony.luck@...el.com
Subject: Re: debug registers and fork

On Tuesday 27 February 2007 00:51, Stephane Eranian wrote:
> Hello,
> 
> I have come across an issue with a monitoring using the
> hardware debug registers on ia64/i386/x86-64.
> 
> It seems that the way debug registers are inherited across fork
> differs between ia-64 and i386/x86-64. On ia-64, the debug registers
> are NEVER inherited in the child. The copy_thread() routine clears
> the necessary thread flags to avoid reloading the debug registers in
> the child.
> 
> Now, on x86-64, it appears that the TIF_DEBUG flag is inherited via
> setup_thread_stack(). By virtue of dup_task_struct() the debug registers
> get copied into the child task on fork. So the child has active breakpoints,
> unless I am mistaken somewhere.
> 
> Given the way the ptrace() interface works, I would tend to
> think that the ia-64 way is the correct one. Any comment?

IA64 is probably correct, but changing this might break existing programs.
Would that be worth the change? What advantage would you have from it.

> Furthermore, on i386/x86-64, when switching out from a task with TIF_DEBUG
> enabled to another which does not, it seems we do not clear the debug
> registers (at least dr7) so they become inactive.

You mean they leak? Perhaps they should be cleared.

-Andi

 
-
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