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

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

Message-ID: <alpine.LFD.2.21.1812161911020.11202@eddie.linux-mips.org>
Date:   Sun, 16 Dec 2018 19:45:00 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Andy Lutomirski <luto@...nel.org>
cc:     Rich Felker <dalias@...c.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, 16 Dec 2018, Andy Lutomirski wrote:

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

 The FPU is a part of the MIPS/Linux psABI and as far as CPU hardware is 
concerned it is typically an RTL option for the customer to control when 
synthesising hardware, just like say the sizes of the caches.  IOW you'll 
have some hardware with FPU and some without that is otherwise identical, 
and maintaining two sets of binaries for what is a part of the psABI 
anyway is often seen as not technically or commercially justified.

 E.g. the (somewhat dated now) 24KEf and 24KEc are complementing standard
MIPS32r2+DSP processor cores with and without the FPU respectively.  Of 
course you can stick to the soft-float ABI instead, but then you'll be 
wasting the FPU resource on FPU cores, so using the hard-float ABI and 
having instructions emulated on non-FPU cores is usually considered a good 
compromise.

 Of course the FPU emulator should have been left to the userland rather 
than put in the kernel, but that mistake was made many years ago and we 
need to maintain compatibility.  Also someone would actually have to 
implement that userland emulator.

 FAOD both GCC and GAS will happily schedule delay slots themselves as 
long as the candidate instruction is recognised as valid in a delay slot, 
so there's no need for anyone to do anything manually for the less common 
instructions to end up in a delay slot.  They just need to appear right 
before a branch or a jump for that to happen.  I can't speak for LLVM.

  Maciej