linux-kernel - Re: PATCH? tracehook_report

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]

Message-Id: <20090601205056.16307FC3C7@magilla.sf.frob.com>
Date:	Mon,  1 Jun 2009 13:50:56 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: PATCH? tracehook_report_clone: fix false positives

> Oh, I never thought about attach && SIGCONT interaction...
> 
> But, tracehook_report_clone() has the same problems?

I don't follow.

> And if we move sigaddset to ptrace_task_init(), we should not worry about
> SIGCONT? Without CLONE_THREAD the new task is not visible to user-space yet.
> Even if we clone a sub-thread, ptrace_init_task() runs under ->siglock.
> If SIGCONT is already pending, copy_process() won't succeed.

It could be pending and blocked.

> Or do you mean something else?

Sorry, I don't think I understood what your question was.
I just pointed out that the element of PTRACE_ATTACH semantics
that would be changed unintentionally if you just replaced its
send_sig_info() call with ptrace_init_task() using sigaddset().


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/