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
architecture.
Without it 'ssh-keygen' crashes pretty fast on attempt to execute
instruction
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 kernel.org 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:
ADDIUPC
AUIPC
ALUIPC
LDPC
LWPC
LWUPC
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.
