linux-kernel - Re: Fixing MIPS delay slot emulation weakness?

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: <CALCETrXBfQ-EnOD3OjQh_BaiFyvULtmrMHoX0nv+=yrp6uHzgQ@mail.gmail.com>
Date:   Sun, 16 Dec 2018 10:59:19 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Rich Felker <dalias@...c.org>
Cc:     "Maciej W. Rozycki" <macro@...ux-mips.org>,
        Andy Lutomirski <luto@...nel.org>,
        Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Paul Burton <paul.burton@...tec.com>,
        David Daney <david.daney@...ium.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>
Subject: Re: Fixing MIPS delay slot emulation weakness?

On Sun, Dec 16, 2018 at 10:13 AM Rich Felker <dalias@...c.org> wrote:
>
> On Sun, Dec 16, 2018 at 01:50:13PM +0000, Maciej W. Rozycki wrote:
> > On Sat, 15 Dec 2018, Rich Felker wrote:
> >
> >
> >  It doesn't help that information about that is scattered across many
> > documents.  You can check for the NODS flag in the opcodes library from
> > binutils though, which is almost 100% accurate, except for the SYNC
> > instructions, for semantic reasons (i.e. they are allowed, but we don't
> > want GAS to reorder them).  Most of the disallowed stuff is in the
> > microMIPS instruction set, due to encodings that execute as hardware
> > macros.
>
> I think it suffices to emulate what compilers generate in delay slots,
> which should be fairly minimal and stable. At the very least we could
> enumerate everything GCC and LLVM already emit there, and get them to
> upstream a policy of not adding new insns as fpu-delay-slot-allowed.
> If someone is writing asm by hand to do ridiculous things in the delay
> slot with random ISA extensions, they shouldn't expect it to work.
>

I feel like I have to ask: the real thing preventing emulation is that
new nonstandard instructions might get used in FPU delay slots on
non-FPU-supporting hardware?  This seems utterly nuts.  If you're
using custom ISA extensions, why on Earth are you also using emulated
floating point instructions?  You're targetting a specific known CPU
if you do this, so you should use only instructions that actually work
on that CPU.