Re: [PATCH v2 0/3] MIPS executable stack protection

From: Leonid Yegoshin
Date: Thu Oct 09 2014 - 19:48:25 EST

On 10/09/2014 03:59 PM, David Daney wrote:

Note: actual execute-protection depends from HW capability, of course.

This patch is required for MIPS32/64 R2 emulation on MIPS R6
Without it 'ssh-keygen' crashes pretty fast on attempt to execute
in stack.

There is much more blocking MIPS32/64 R2 emulation on MIPS R6 than
just this patch isn't there?

This one is critical - ssh-keygen crashes during running MIPS R2. I have
a patch in my R6 repository but GLIBC still can't set stack executable
and security suffers.

But is the R6 code already in the lmo or repositories?

If not, then the lack of this patch is not a gating issue. If this patch is really needed for R6 support, why not submit the R6 prerequisite patches first?

Because -

1) security concern still does exist for MIPS R5 (MIPS R2 has no RI/XI support, it was defined in MIPS R3 but for simplicity it is referred as "MIPS R2")
2) GLIBC need that to start development

If this patch has nothing to do with MIPS R6, then state that.

It has value for both - MIPS R5 and MIPS R6.

Also, if you are supporting MIPS R6, this patch doesn't even work,
because it doesn't handle PC relative instructions at all.

It seems like you missed my statement - adding support for PC-relative
instruction is just 5 lines of code. I just refrain from this until
toolchain starts generating that.

How can it be just 5 lines of code? You have to emulate all those instructions:


I think that is all of them. You can emulate all of those in 5 lines of code?

You misread my statement - 5 lines of code for PC-related instruction. And only ADDIUPC is a part of microMIPS R2 which I can emulate.
But we discuss something insignificant, MIPS R6 load instructions takes more, of course, but definitely less than LWL/LWR/LDL/LDR which I should emulate anyway and do.

We need to support everything the toolchain could product in the future. I don't think it makes sense to add all this stuff when it is well known that it doesn't solve the problem for MIPS R6, especially when the justification for the patch is that it is needed for R6.

I understand what your goals are here, I have spend many months working towards a non-executable stack (see the patches that moved the signal trampolines off the stack). But I am worried that there are many cases that it will not handle.

Besides that, this version 2 of patch just passed 20-22 hours on P5600
and Virtuoso (no FPU on both) under SOAK test and it gets around 1 per
hour of signal right at emulated instruction in VDSO and unwind works
(as I can see in debug prints).

I'm not saying that the patch doesn't work under your highly constrained test conditions, I believe that it does.

I am not familiar with the SOAK test. Does it really put faulting instructions the delay slots of FP branch instructions, catch the resulting signal, and then throw an exception from the signal handler?

Yes, the debug output shows me that. "from the signal handler" -> "to the signal handler"?

The recent discussions on this subject, including many comments from
Imgtec e-mail addresses, brought to light the need to use an
instruction set emulator for newer MIPSr6 ISA processors.

In Imgtec I am only one who works on MIPS R6 SW and FPU branch emulation
and I say you - it is not needed, this solution is enough.

It can't be true the PC relative support is not needed, why did you add the PC relative instructions, if you didn't want to use them in Linux userspace?

Sorry, I misunderstood you here - I assume you told here about FULL INSTRUCTION SET emulator. Of course, some emulation is needed like PC relative instructions, but not a full instruction set. I never said that PC-relative instruction doesn't require an emulation.

But see your point (1) below, if you retract from that HERE, please confirm the difference - do you want a full instruction set emulator or you speak about only PC relative instructions?

> Here is my proposal:

> 1) Add an emulator for all documented MIPS R6 instructions that can appear in a linux userspace delay slot.

> 2) Document as not supported placing COP2 instructions in FP branch delay slots.

> 3) Get rid of this execute-out-of-line code in the FPU emulator all together.

> 4) Enable non-execute stack.

> In order to have full MIPS R6 support in the kernel, you will need an emulator for a subset of the instructions anyhow. Going to a full ISA emulator will be a little
> more work, but it shouldn't be too hard.

It is too restrictive and kills the idea of customised processor.

- Leonid.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at