linux-kernel - Re: situation with signals

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: <20101027213745.GI19804@ZenIV.linux.org.uk>
Date:	Wed, 27 Oct 2010 22:37:45 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: situation with signals

On Wed, Oct 27, 2010 at 05:02:10PM -0400, Chris Metcalf wrote:

> I set aside this thread to look at when I had a minute, and I believe there
> is just one of the signal issues present in the tile code.  The fix is to
> reset regs->fault to something other than the "syscall" fault type when
> exiting from do_signal(), so I'll submit that up for 2.6.37 shortly.
> 
> Otherwise I think tile is doing things right, though I admit, the signal
> support is pretty deep magic generally.

FWIW, I'd do that in handle_signal() when hitting a syscall restart.
BTW, is everything in your pt_regs safe to modify?  I.e. could bogus
values put there by sigreturn lead to something like kernel mode being
retained when you return from syscall or interesting flags being
set, etc.?
--
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/