linux-kernel - [PATCH 0/2] More FCSR handling fixes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1610272159160.31859@tp.orcam.me.uk>
Date:   Fri, 28 Oct 2016 08:19:10 +0100
From:   "Maciej W. Rozycki" <macro@...tec.com>
To:     Ralf Baechle <ralf@...ux-mips.org>
CC:     Paul Burton <paul.burton@...tec.com>,
        James Hogan <james.hogan@...tec.com>,
        <linux-mips@...ux-mips.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH 0/2] More FCSR handling fixes

Hi,

 Here are some further fixes to our FCSR handling.  Just 2 changes at this 
time.

 The first, very small one, closes an issue where a write made with 
ptrace(PTRACE_POKEUSR, ...) to FCSR does not mark the FP context as used.  
This is the legacy interface, seldom used these days, having been largely 
replaced with ptrace(PTRACE_SETFPREGS, ...), so the problem may have 
escaped easily.  Fixed now.

 The second, larger one, addresses the handling of the Cause bits, by 
letting them remain set in some cases, making their semantics more 
consistent with what hardware does when undisturbed; a SIGFPE signal is 
sent if appropriate where previously it was missed.

 This change is not final as in some cases, specifically in the FP context 
of SIGFPE's signal frame, active Cause bits that match Enable bits will 
still be recorded as clear even though they were originally set, being the 
reason for the signal.  Consequently the signal will not retrigger if the 
handler returns with the FP context unchanged in the signal frame.  This 
is unlike with other signals triggered by a hardware exception which do 
require a corrective action if a return is intended rather than an escape 
via `longjmp' or suchlike and which is what one would expect here as well.

 I plan to address this final issue with a further change in the future, 
however I have not started this effort yet and I don't have a schedule 
set.  Meanwhile this change is I believe a step in the right direction.

 Details of both changes have been provided with individual patch 
descriptions.

 While making these changes I have noticed a bunch of bitrot issues we 
have with the handling of the FP context in signal frames with MIPS I-II 
processors.  I will submit corrections as a separate patch series.

 Questions or comments are welcome, as usually, and otherwise please queue
for the next merge cycle.

  Maciej