linux-kernel - Re: [PATCH 1/1] arm: vfp: Raising SIGFPE on invalid floating point operation

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] [day] [month] [year] [list]

Date:	Fri, 3 Feb 2012 15:11:25 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Kautuk Consul <consul.kautuk@...il.com>
Cc:	Dave Martin <dave.martin@...aro.org>,
	"Mohd. Faris" <mohdfarisq2010@...il.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/1] arm: vfp: Raising SIGFPE on invalid floating point
	operation

On Fri, Feb 03, 2012 at 08:07:02PM +0530, Kautuk Consul wrote:
> The **E bits(DZE/IOE/etc) are non-programmable on my system and they
> are set to 0
> however I try to play with them.

If the E bits are always zero, your VFP is incapable of _signalling_
the corresponding exception conditions.  Or, to put it another way,
those exception conditions are always masked.

And, if DZE is always zero, which is the divide-by-zero exception, then
obviously it won't raise an exception when you _do_ ask it to divide by
zero.  Instead, it will just set the cumulative exception status.

And, again, obviously, if it doesn't raise an exception, there is no
way for the system to deliver a SIGFPE to the user process.

Userspace does need to deal with this - as Dave points out, having
feenableexcept() return an error of the *E bits can't be set would
seem to be the sensible thing to do.  Whether or not user programs
even use that call (most, I suspect don't) is a separate problem.
--
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/