linux-kernel - Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

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: <5434343E.2090308@caviumnetworks.com>
Date:	Tue, 7 Oct 2014 11:43:10 -0700
From:	David Daney <ddaney@...iumnetworks.com>
To:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
CC:	Matthew Fortune <Matthew.Fortune@...tec.com>,
	David Daney <david.s.daney@...il.com>,
	Rich Felker <dalias@...c.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Daney <ddaney.cavm@...il.com>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

On 10/07/2014 11:32 AM, Leonid Yegoshin wrote:
> Well, I am not a subscriber to mail-list, so I read it the first time
> and some notes:
>
> 1)  David's approach would likely work for FPU emulation but unlikely
> works for MIPS Rel 2/Rel 1/ MIPS I emulation in MIPS R6 architecture.
> The reason is that the first MIPS R2 instruction (removed from MIPS R6)
> can be hit long before GLIBC/bionic/etc can determine how to use
> properly a new system call. And that instruction needs to be emulated. I
> actually hit this problem with ssh-keygen first and referred to  FPU
> emulation because I got it later, during my attempt to salvage a situation.
>
> 2)  The issue of uMIPS ADDIUPC and similar instructions are overblown in
> my opinion. Never of them are memory-related and their emulation in
> BD-slot can be easily done in kernel and that actually accelerates an
> emulation. Look at piece of code which I wrote to accelerate an
> emulation of some instructions in BD-slot of JR instruction:
>
>          switch (MIPSInst_OPCODE(ir)) {
>          case addiu_op:
>                  if (MIPSInst_RT(ir))
>                          regs->regs[MIPSInst_RT(ir)] =
> (s32)regs->regs[MIPSInst_RS(ir)] +
>                                  (s32)MIPSInst_SIMM(ir);
>                  return(0);
> #ifdef CONFIG_64BIT
>          case daddiu_op:
>                  if (MIPSInst_RT(ir))
>                          regs->regs[MIPSInst_RT(ir)] =
> (s64)regs->regs[MIPSInst_RS(ir)] +
> (s64)MIPSInst_SIMM(ir);
> return(0);
> #endif
>
> Five lines per instruction.

But you must be able to emulate them, so you need an emulator, not XOL.

>
> 3)  The signal happened during execution of emulated instruction -
> signals are under control of kernel and we can easily delay a signal
> during execution of emulated instruction until return from do_dsemulret.
> It is not a big deal - nor code, nor performance. Thank you for good point.
>

The problem is what to do with synchronous signals (SIGSEGV)  Those 
cannot be held off, and you really want the EPC value saved in the 
register state to be correct.

> 4)  The voice for doing any instruction emulation in kernel - it is not
> a MIPS business model to force customer to put details of all
> Coprocessor 2 instructions public. We provide an interface and the rest
> is a customer business. Besides that it is really painful to make a
> differentiation between Cavium Octeon and some another CPU instructions
> with the same opcode. On other side, leaving emulation of their
> instructions to them is not a wise after having some good way doing that
> multiple years.
>

With all the new information we have begun to understand, it seems like 
the only sane thing to do is get rid of this XOL approach and go to full 
emulation of the entire instruction set.

David Daney

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/