linux-kernel - [PATCH 0/1] tile: do_hardwall_trap: do not play with task->sighand

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:	Tue, 26 Apr 2011 22:36:44 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Chris Metcalf <cmetcalf@...era.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: [PATCH 0/1] tile: do_hardwall_trap: do not play with task->sighand

On 04/22, Chris Metcalf wrote:
>
> On 4/21/2011 9:03 PM, Oleg Nesterov wrote:
> > 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.

OK. In this case the thread-specific SIGILL makes more sense afaics.

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

Great. I am sending the same patch + the changelog.

Please do not forget, I know _nothing_ about arch/tile, and of course the
patch was not tested.

Oleg.

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