lkml.org 
[lkml]   [2014]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/3] MIPS executable stack protection
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.



\
 
 \ /
  Last update: 2014-10-10 02:21    [W:1.424 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site