linux-kernel - Re: debug registers and fork

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]

Message-Id: <200703051825.16473.ak@suse.de>
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/