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: <de07ff44-41ee-4158-b629-90a1835bd9cb@app.fastmail.com>
Date: Fri, 12 Jul 2024 08:36:45 +0800
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
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

在2024年7月11日七月 下午6:20，Maciej W. Rozycki写道：
> On Thu, 11 Jul 2024, Jiaxun Yang wrote:
>
>> >> that's just one case, what about NaN2008 binaries on a legacy MIPS CPU ?
>> >
>> >  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).

>
>> 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.

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

Thanks
>
>   Maciej

-- 
- Jiaxun