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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <543709D0.6000501@imgtec.com>
Date:	Thu, 9 Oct 2014 15:18:56 -0700
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	David Daney <ddaney.cavm@...il.com>
CC:	<linux-mips@...ux-mips.org>, <Zubair.Kakakhel@...tec.com>,
	<geert+renesas@...der.be>, <david.daney@...ium.com>,
	<peterz@...radead.org>, <paul.gortmaker@...driver.com>,
	<davidlohr@...com>, <macro@...ux-mips.org>, <chenhc@...ote.com>,
	<richard@....at>, <zajec5@...il.com>, <james.hogan@...tec.com>,
	<keescook@...omium.org>, <alex@...x-smith.me.uk>,
	<tglx@...utronix.de>, <blogic@...nwrt.org>,
	<jchandra@...adcom.com>, <paul.burton@...tec.com>,
	<qais.yousef@...tec.com>, <linux-kernel@...r.kernel.org>,
	<ralf@...ux-mips.org>, <markos.chandras@...tec.com>,
	<dengcheng.zhu@...tec.com>, <manuel.lauss@...il.com>,
	<akpm@...ux-foundation.org>, <lars.persson@...s.com>
Subject: Re: [PATCH v2 0/3] MIPS executable stack protection

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.

>
>>
>> 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.

>
> 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.

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).

>
>
> 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.

>
> 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.

- Leonid
--
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/