linux-kernel - Re: [PATCH 1/14] move user_enable_single_step & co prototypes to linux/ptrace.h

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: <20100210220323.GA10365@lst.de>
Date:	Wed, 10 Feb 2010 23:03:23 +0100
From:	Christoph Hellwig <hch@....de>
To:	Roland McGrath <roland@...hat.com>
Cc:	Christoph Hellwig <hch@....de>, oleg@...hat.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, mattst88@...il.com,
	ink@...assic.park.msu.ru, rth@...ddle.net, linux@....linux.org.uk,
	hskinnemoen@...el.com, vapier@...too.org, starvik@...s.com,
	jesper.nilsson@...s.com, ysato@...rs.sourceforge.jp,
	takata@...ux-m32r.org, gerg@...inux.org, monstr@...str.eu,
	ralf@...ux-mips.org, jdike@...toit.com, chris@...kel.net
Subject: Re: [PATCH 1/14] move user_enable_single_step & co prototypes to linux/ptrace.h

On Mon, Feb 08, 2010 at 11:51:25AM -0800, Roland McGrath wrote:
> The original thought there was that user_enable_single_step() et al might
> well be only an instruction or three on a sane machine (as if we have any
> of those!), and since there is only one call site inlining would be
> beneficial.  But I agree that there is no strong reason to care about
> inlining it.

In fact many of the implementations are small enough to inline them, but
not no architecture so far decided to inline them, and in the end it's
not exactly a fast-path.  This at least keeps the prototype the same
everywhere.

> As to the arch changes, there is only one thought I'd add to the record.
> It was always my thinking that for an arch where PTRACE_SINGLESTEP does
> text-modifying breakpoint insertion, user_enable_single_step() should not
> be provided.  That is, arch_has_single_step()=>true means that there is an
> arch facility with "pure" semantics that does not have any unexpected side
> effects.  Inserting a breakpoint might do very unexpected strange things in
> multi-threaded situations.  Aside from that, it is a peculiar side effect
> that user_{enable,disable}_single_step() should cause COW de-sharing of
> text pages and so forth.  For PTRACE_SINGLESTEP, all these peculiarities
> are the status quo ante for that arch, so having arch_ptrace() itself do
> those is one thing.  But for building other things in the future, it is
> nicer to have a uniform "pure" semantics that arch-independent code can
> expect.

For now the ptrace code is the same for real or software singlestepping.
If we grow users that care we can add a arch_has_hw_single_step macro
or just overload arch_has_single_step with different postitive return
values for the exact same type of single stepping supported.

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