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:	Fri, 18 Jun 2010 11:00:53 +0100
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	"Gleb O. Raiko" <raiko@...si.msk.ru>
Cc:	David Daney <ddaney@...iumnetworks.com>,
	Jesper Nilsson <jesper@....nu>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org
Subject: Re: MIPS: return after handling coprocessor 2 exception

On Fri, Jun 18, 2010 at 11:54:38AM +0400, Gleb O. Raiko wrote:

> >What happens when the call chain is empty, and the proper action *is*
> >SIGILL?
> 
> It's never empty, in fact. The default notifier declared at top of
> traps.c sends SIGILL. The problem that current code is sending
> SIGILL in all cases.

That's not really a problem.  The design idea is that a the default
notifier has the lowest priority, that is any user notifier installed
should have higher priority resulting in it getting run first.  To avoid
the default notifier from getting executed such an extra notifier should
set NOTIFY_STOP_MASK in its return like:

static int default_cu2_call(struct notifier_block *nfb, unsigned long action,
        void *data)
{
	...

	return NOTIFY_OK | NOTIFY_STOP;
}

The notifier list could also be used for example by perf but there it
we'd want the notifier function not to return NOTIFY_STOP as the result;

Arguably sending the signal for CU2 instructions has been delegated to the
hook so the I agree that the break stateement should be replaced with a
return and will apply the patch.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ