linux-kernel - Re: [PATCH 04/11] ptrace: implement 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:	Mon, 9 May 2011 12:55:41 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	oleg@...hat.com, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT

On Mon, May 9, 2011 at 12:09 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On Sun, May 08, 2011 at 11:58:20PM +0200, Denys Vlasenko wrote:
>> Are rules for PTRACE_INTERRUPT the same? That is, what happens
>> if a different trap is taken?
>
> Oh, PTRACE_INTERRUPT is different.  If it's scheduled, it will
> eventually happen.  Other traps may happen before but INTERRUPT trap
> will take place before control is returned to userland.
>
>> Can you add API notes in the header, above corresponding defines? -
>>
>> --- a/include/linux/ptrace.h
>> +++ b/include/linux/ptrace.h
>> @@ -48,6 +48,7 @@
>>  #define PTRACE_SETREGSET       0x4205
>>
>> <============================================ ADD COMMENT HERE
>>  #define PTRACE_SEIZE           0x4206
>> <============================================ ADD COMMENT HERE
>> +#define PTRACE_INTERRUPT       0x4207
>>
>>
>> They will be much more visible and up-to-date there than in Documentation,
>> git logs etc...
>
> Hmmm... I was thinking about writing a proper ptrace API doc with
> example programs under Documentation/.  It's userland visible API so
> it shouldn't change all that much

My motivation is mostly to prevent or make it less likely for someone
who will hack on this code in the future to misunderstand semantics
of these ops. A hacker changing PTRACE_INTERRUPT-related code
is much more likely to notice a comment above PTRACE_INTERRUPT
definition than a file buried in Documentation/.

> and the amount of necessary
> documentation would be too much for comments.

Yes, if you'd try to put there a comprehensive doc.
The comment I envision is short, yet captures the most important
traits of the operation. For example:

/* After PTRACE_SEIZE, tracee will trap - once. It may be a signal delivery
 * or group stop, if one is already pending; otherwise,
 * a SIGTRAP | (PTRACE_EVENT_INTERRUPT << 8) trap is taken.
 * A trap will happen in finite amount of userland time.
 */
#define PTRACE_SEIZE           0x4206

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