linux-kernel - Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE

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:	Thu,  3 Feb 2011 13:36:39 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after
	PTRACE_ATTACH

IMHO this sort of band-aid does not really help the overall situation.
It takes something that is intricate and fiddly and just fiddles it a
bit more.  Userland will still have to handle older kernels where this
behavior is not there.  If userland does anything that relies on this
new behavior, then it will have to try somehow to figure out which
kernel versions have which behavior and adapt, etc.

When the old behaviors are unhelpful like this, I think it is really
better to add new mechanisms instead.  We can make new mechanisms more
clear and straightforward for userland to work with from the beginning.
Then the compatibility picture for userland is simply to try a new call
or new ptrace request or new option bit or whatever it is.  When the
kernel supports the new thing, things are easy.  When it doesn't, then
they cope with life as they have been coping before on old kernels.

I have some ideas about new things to add for this problem area.  But
we have to think those through carefully and discuss all the details
thoroughly with Jan and other folks working on userland debuggers
before we write the kernel side.

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/