linux-kernel - Re: [PATCH 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <tg3ek4qtursbob5wootj8r09.1412436788097@email.android.com>
Date:	Sat, 4 Oct 2014 15:33:36 +0000
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	Zubair Kakakhel <Zubair.Kakakhel@...tec.com>,
	"david.daney@...ium.com" <david.daney@...ium.com>,
	"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
	"davidlohr@...com" <davidlohr@...com>,
	"macro@...ux-mips.org" <macro@...ux-mips.org>,
	"chenhc@...ote.com" <chenhc@...ote.com>,
	"zajec5@...il.com" <zajec5@...il.com>,
	James Hogan <James.Hogan@...tec.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"alex@...x-smith.me.uk" <alex@...x-smith.me.uk>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"blogic@...nwrt.org" <blogic@...nwrt.org>,
	"jchandra@...adcom.com" <jchandra@...adcom.com>,
	Paul Burton <Paul.Burton@...tec.com>,
	Qais Yousef <Qais.Yousef@...tec.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	Markos Chandras <Markos.Chandras@...tec.com>,
	"manuel.lauss@...il.com" <manuel.lauss@...il.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lars.persson@...s.com" <lars.persson@...s.com>
Subject: Re: [PATCH 0/3] MIPS executable stack protection

Peter Zijlstra wrote:

>> It sets up a per-thread 'VDSO' page and appropriate TLB support.

> So traditionally we've always avoided per-thread pages like that.
> What makes it worth it on MIPS?

MIPS has branch delay slots - it is an instruction after branch which is executed
before branch is taken. If branch fails due to FPU unavailability then that
instruction should be emulated as well as branch itself.
However, MIPS allows to have a customisable coprocessor 2 instructions
and it is impractical to emulate it and big amount of other traditional MIPS
instructions inside of kernel.

So, some per thread space is needed to put instruction into it, enclose it with
a return kernel call and switch temporary execution into it.

Currently, this space is space at SP register (user stack) but it prevents
switching stack as non-executable.

Handle another stack set (one stack per thread) in common user map is
impractical because of management, scalability and performance difficulties.