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.2407121250350.38148@angie.orcam.me.uk>
Date: Fri, 12 Jul 2024 13:22:49 +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 Fri, 12 Jul 2024, Jiaxun Yang wrote:

> >> >  It would be good to check with hard-float QEMU configured for writable 
> >> > FCSR.NAN2008 (which is one way original code was verified) that things 
> >> > have not regressed.  And also what happens if once our emulation has 
> >> > triggered for the unsupported FCSR.NAN2008 mode, an attempt is made to 
> >> > flip the mode bit via ptrace(2), e.g. under GDB, which I reckon our 
> >> > emulation permits for non-legacy CPUs (and which I think should not be 
> >> > allowed under the new setting).
> >> 
> >> PTrace is working as expected (reflects emulated value).
> >
> >  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?

 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.

 In other words we need to be consistent and the NaN mode of operation has 
to be strapped in "ieee754=emulated" mode according to ELF file header's 
EF_MIPS_NAN2008 bit for the duration of execution of a given program.

 Likewise FCSR.ABS2008.

> >> The actual switchable NaN hardware (M5150, P5600) uses a dedicated Config7
> >> bit rather than writable FCSR.NAN2008 to control NaN2008 mode. This is undocumented
> >> and not present on some RTL releases. FCSR.NAN2008 is R/O as per The MIPS32 Instruction
> >> Set Manual. This renders the purposed test pointless.
> >
> >  Yes, for R6 and arguably R5, but not for R3.  Architecture specification 
> > revisions 3.50 through 5.02 define FCSR.NAN2008 (and also FCSR.ABS2008) as 
> > either R/O or R/W, at the implementer's discretion, so it is a conforming 
> > implementation to have these bits writable and our FPU emulator reflects 
> > it.  I won't go into the details here as to why the later revisions of the 
> > specification have been restricted to the R/O implementation only.
> >
> >  NB architecture specification revisions 3.50 through 5.01 also have the 
> > FCSR.MAC2008 bit defined, removed altogether later on.
> 
> Thanks for the information, I don't have access to those manuals so I was unaware
> of that. R/W NAN2008 is prohibited by AVP as well.

 There is a mention in revision history at the end of the current document 
anyway, which in this case is perhaps more informative than individual 
documents themselves.

> I briefly tested NaN2008 distro on QEMU modified with r/w NaN2008 bits in ieee754=
> strict mode, it seems working fine.

 Good.

  Maciej