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]

Date:	Mon,  8 Feb 2010 11:51:25 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Christoph Hellwig <hch@....de>
Cc:	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

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.

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.

OTOH, all such arch issues are really up to the arch maintainer.  As of
today, there is nothing but ptrace using user_enable_single_step() et al so
it's a distinction without a practical difference.  If/when there are other
facilities that use user_enable_single_step() and might care, the affected
arch's can revisit the question when someone cares about the quality of the
arch support for said new facility.

So, with those caveats preserved for posteriority, all these changes
are OK with me.

Thanks,
Roland
--
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/