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

From: David Daney
Date: Thu Oct 09 2014 - 18:59:48 EST

On 10/09/2014 03:18 PM, Leonid Yegoshin wrote:
On 10/09/2014 02:42 PM, David Daney wrote:
On 10/09/2014 01:00 PM, Leonid Yegoshin wrote:
The following series implements an executable stack protection in MIPS.

It sets up a per-thread 'VDSO' page and appropriate TLB support.
Page is set write-protected from user and is maintained via kernel VA.
MIPS FPU emulation is shifted to new page and stack is relieved for
execute protection as is as all data pages in default setup during ELF
binary initialization. The real protection is controlled by GLIBC and
it can do stack protected now as it is done in other architectures and
I learned today that GLIBC team is ready for this.

What does it mean to be 'ready'? If they committed patches before
there was kernel support, that it putting the cart before the horse.
GlibC's state cannot be used as valid reason for committing major
kernel changes. There would be no regression in any GLibC based
system as a result of not merging this patch.
Rich Fuhler said me that they discussed it internally and have a
solution to fix their problem (ignoring PT_GNU_STACK on first library
load - they need to sort out the logic). But we need to split both issue
- right now stack can't be protected because of emulation. If they set
stack protected then emulation fails on CPU without FPU.

Yes, we understand why non-executable stack is not compatible with the FPU emulator.

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?

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

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?

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?

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?

Really what I was talking about was a wider audience, the people that will write tools and code that target userspace. They will want a solution without a bunch of restrictions forced upon them by the limitations of the FPU emulator.

In light of this, why does it make sense to merge this patch, instead
of taking the approach of emulating the instructions in the delay slot?

Well, because it does exist now. But full MIPS emulator... for all
ASEs... for any MIPS vendor... I even doesn't want to estimate an amount
of time and code size to develop it.

Besides that, you missed my another statement - we don't force customer
to disclose all details of their COP2 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.

David Daney
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