linux-kernel - Re: PROBLEM: Caught SIGFPE exceptions aren't reset

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]

Message-ID: <18128.322.59087.367556@alkaid.it.uu.se>
Date:	Sat, 25 Aug 2007 12:15:30 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	"Clark Cooper" <clark.cooper@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: Caught SIGFPE exceptions aren't reset

Clark Cooper writes:
 > [1] Caught SIGFPE exceptions aren't reset
 > 
 > [2]
 >     On an i386, you can set a handler for a SIGFPE signal, and after enabling FP
 >     exceptions with feenableexceptions(), an FP exception will cause
 > your handler
 >     to be called.  However after the handler returns, it is called
 > again with the
 >     same FP error.  Control never returns to the point after the
 > instruction that
 >     caused the exception.

User error.

You cannot write working SIGFPE handlers without understanding the
underlying FP instruction set and its exception model, and being
prepared to write CPU- and OS-specific code.

In particular, on modern x86, an SSE2 FP instruction that raises
an exception will be set to restart in the resumption state.
It's up to your handler to either bypass the restart (longjmp),
or to update the resumption state so that it can be resumed without
triggering an infinite loop. Your handler can do this by masking
exceptions, changing the operands of the failed FP instruction,
or by changing the PC so that the failed instruction is skipped
(your handler may want to emulate the instruction in this case).

This is not a kernel problem.

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