linux-kernel - Re: arch/tile/kernel/hardwall.c:do_hardwall

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: <4DB17CDE.3050603@tilera.com>
Date:	Fri, 22 Apr 2011 15:04:30 +0200
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	Matt Fleming <matt@...sole-pimps.org>, Tejun Heo <tj@...nel.org>,
	<linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt.fleming@...ux.intel.com>
Subject: Re: arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage
 of	->sighand

On 4/21/2011 9:03 PM, Oleg Nesterov wrote:
> On 04/18, Oleg Nesterov wrote:
>> On 04/16, Matt Fleming wrote:
>>> 	3. I suspect most people find the rules of ->sighand pretty
>>> 	confusing. Just look at
>>>
>>> 		arch/tile/kernel/hardwall.c:do_hardwall_trap()
>>>
>>> 	the use of siglock there looks buggy to me.
>> Indeed, I agree. It shouldn't use __group_send_sig_info() at all.
>> I'll send the patch. Nobody outside of signal code should play with
>> ->sighand, this is almost always wrong.
> Hmm. It turns out, I can't make the patch because I do not understand
> what this code tries to do.
>
> hardwall_activate() adds the thread to hardwall_list, but do_hardwall_trap()
> sends the signal to the whole process. I know nothing about arch/tile and
> probably this is correct, but could you confirm this?

Yes, the intended behavior is to send the signal to the process, as a way
of indicating the OS's displeasure with sending a malformed packet on the
user network.  But I think sending it to the specific thread is reasonable
too; I don't have a strong preference in this design.

> Note that SIGILL can be delivered to another thread in the thread-group, is
> it correct?
>
> Also. Is it supposed that SIGILL can have a hanlder or can be blocked, or
> it should always kill the whole thread group?

A handler would be reasonable for the process.

> I think we need the patch below, assuming that SIGILL should be sent to
> the single thread and it is fine to have a handler for SIGILL.

Thanks; I appreciate the additional code review in any case.  I'll look at
the ramifications of the change in more detail when I return from vacation
late next week.

> Oleg.
>
> --- sigprocmask/arch/tile/kernel/hardwall.c~1_sighand	2011-04-06 21:33:42.000000000 +0200
> +++ sigprocmask/arch/tile/kernel/hardwall.c	2011-04-21 20:56:36.000000000 +0200
> @@ -268,12 +268,10 @@ void __kprobes do_hardwall_trap(struct p
>  	found_processes = 0;
>  	list_for_each_entry(p, &rect->task_head, thread.hardwall_list) {
>  		BUG_ON(p->thread.hardwall != rect);
> -		if (p->sighand) {
> +		if (!(p->flags & PF_EXITING)) {
>  			found_processes = 1;
>  			pr_notice("hardwall: killing %d\n", p->pid);
> -			spin_lock(&p->sighand->siglock);
> -			__group_send_sig_info(info.si_signo, &info, p);
> -			spin_unlock(&p->sighand->siglock);
> +			do_send_sig_info(info.si_signo, &info, p, false);
>  		}
>  	}
>  	if (!found_processes)
>

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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