linux-kernel - Re: getter PTRACE_GETSIGINFO should not modify anything [Re: [PATCH 11/11] ptrace: implement group stop notification for ptracer]

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 15 May 2011 19:28:11 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	oleg@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: getter PTRACE_GETSIGINFO should not modify anything  [Re:
 [PATCH 11/11] ptrace: implement group stop notification for ptracer]

Hello,

On Sun, May 15, 2011 at 07:17:48PM +0200, Jan Kratochvil wrote:
> just a general point for all the mails:
> 
> On Sun, 15 May 2011 16:28:27 +0200, Tejun Heo wrote:
> > Even for LD_PRELOAD, it can simply keep scheduling INTERRUPT
> > until the application calls the wrapped GETSIGINFO when it detects the
> > stopped state has changed.  It can be easily done from userland.
> 
> I thought the goal is to simplify the interface, not making it even more
> complicated.

It's a balancing act.  The primary goal is to make it _functional_ as
the current ptrace is outright broken in many places.  The second, at
least for me, is not deviating from the current behavior too much
unless required by the first goal or not doing so is extremely silly.

It would be nice to have a concise pretty interface but we already
have this ugly thing which works half ways and it's not like the
current users can drop support for old kernels quickly, so I don't see
a lot of benefit in making changes for prettiness, but please note
that I'm not trying to make it any more complicated.  It won't be
pretty but won't be more complicated than now either.

After all, this is a pretty low level API which only a handful are
gonna use.  If it involves some ugliness to use it, as long as no
functionality is compromised, I would go that way than introducing
larger behavior difference from the current one.

That said, give me strong enough reasons, I'll be happy to change the
behavior.

And, thanks a lot for your comments.  I really appreciate them.

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