linux-kernel - Re: [PATCH v3] MIPS: Implement ieee754 NAN2008 emulation mode

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: <alpine.DEB.2.21.2407150225310.58077@angie.orcam.me.uk>
Date: Mon, 15 Jul 2024 13:15:12 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org, 
    linux-kernel@...r.kernel.org, 
    "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
    Philippe Mathieu-Daudé <philmd@...aro.org>
Subject: Re: [PATCH v3] MIPS: Implement ieee754 NAN2008 emulation mode

On Sun, 14 Jul 2024, Jiaxun Yang wrote:

> >> >  Yes, sure for reads, but how about *writing* to the bit?
> >> 
> >> Tested flipping nan2008 bits with ieee754=emulated with ptrace, it works on some extent.
> >> (flipping the bit to unsupported value immediately triggered emulation).
> >
> >  What about the other way round?
> 
> It works on both side (NaN2008 binary with ptrace flipped back to legacy and legacy flipped
> back to NaN2008).

 So this is clearly wrong for this scenario.

> >  Anyway I think we need to prevent it from happening, matching runtime 
> > behaviour, i.e. if the program itself cannot flip FCSR.NAN2008 via CTC1, 
> > then ptrace(2) must not either.  And the same for the emulator in the 
> > "ieee754=emulated" mode (but not for the emulator modes where the flipping 
> > is currently permitted), as it would be a one-way switch.
> 
> It is out of the scope of this patch I think. Maybe we need a prctl to 
> set NaN2008 status.

 I don't know what prctl(2) has to do with this.  If you don't implement 
this part, then your change will cause Linux to behave inconsistently and 
therefore I'll have to NAK it.

 It's not much to do anyway, as I have prepared `ptrace_setfcr31' already 
to handle masking correctly, so all you have to do is to set the mask as 
required for the right thing to happen.  I shouldn't have needed to point 
you at it though, as that code is easy to find.

> We are unable to prevent user applications write NAN2008 bits for the "switchable
> QEMU" as well. So I'd perfer leave it as is, and let this feature go into 6.11 so people
> can start to use it.

 This doesn't matter either, as your change only addresses the case where 
FCSR.NAN2008 isn't writable anyway, which is the sole reason you want to 
switch between native hard float support and emulation, doesn't it?

 In fact where FCSR.NAN2008 is writable your new mode has to be equivalent
to "ieee754=strict", because then there is no need to trigger emulation 
for either NaN mode.  Please do verify that this is the case.

> This is actually a request from Debian MIPS team so they can get glibc tests run on
> mismatched NaN hardware.

 That doesn't matter for us here (and I have a bad suspicion anyway), but 
the Debian team is of course free to do what they want here, the GNU GPL 
applies.

 And also they can always use the "nofpu" kernel parameter to run their 
verification.  I used it for mine back at ImgTec before 2008 NaN hardware 
was available, also to verify emulation, which I wrote too.  Perhaps that 
is also the right solution for Debian actually?

  Maciej