linux-kernel - Merging ptrace branch into mainline

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110722103059.GK2622@htj.dyndns.org>
Date:	Fri, 22 Jul 2011 12:30:59 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Merging ptrace branch into mainline

Hello,

Most of the changes that I had on mind when I wrote "Proposal for
ptrace improvements"[1] seem complete.  The details of course changed
quite a bit during implementation iterations but AFAICS all the
features and fixes described in the propsal are now in Oleg's tree
waiting to be pulled into mainline.  New features are still blocked by
the DEVEL flag indicating the API is not finalized yet and should be
used only for developement.

Remaining issues are

* Two different modes of trap notification - directly ptrace_notify()
  and force_sig(SIGTRAP), which makes SIGTRAP special w.r.t. ptrace.

  There are two alternatives.  One is converting SIGTRAP notifications
  into (async) ptrace_notify() notifications.  The other is to leave
  it alone and just declare that SIGTRAP indeed is special and
  userland programs playing with SIGTRAP won't behave transparently
  while ptraced.

  I haven't really looked at it too much but am currently leaning
  towards the latter.

* Somewhat related.  Some part of ptrace, especially breakpoint and
  singlestep handling, is more arch-specific than necessary and archs
  diverged on what is reported how.  Most of this should be unifiable
  or at least categorized.

Neither is very critical and we shouldn't be introducing drastic
userland visible behavior differences no matter which way we choose,
but given that this isn't an urgent thing, I think it would be best to
merge the pending ptrace changes with the DEVEL blocking enabled for
3.1, so that we can have more time settling down things and hopefully
seeing how it works with actual userland usage.

What do you guys think?

Thank you.

-- 
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/1107045
--
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/