linux-kernel - Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Oct 2014 12:24:06 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	James Hogan <james.hogan@...tec.com>
Cc:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	linux-mips@...ux-mips.org, Zubair.Kakakhel@...tec.com,
	geert+renesas@...der.be, david.daney@...ium.com,
	paul.gortmaker@...driver.com, davidlohr@...com,
	macro@...ux-mips.org, chenhc@...ote.com, richard@....at,
	zajec5@...il.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 2/3] MIPS: Setup an instruction emulation in VDSO
 protected page instead of user stack

On Fri, Oct 10, 2014 at 11:03:34AM +0100, James Hogan wrote:
> Hi Leonid,
> 
> On Thu, Oct 09, 2014 at 05:07:11PM -0700, Leonid Yegoshin wrote:
> > On 10/09/2014 04:40 PM, James Hogan wrote:
> > > You could then avoid the whole stack and per-thread thing and just have
> > > a maximum of one emuframe dedicated to each thread or allocated on
> > > demand, and if there genuinely is a use case for nesting later on, worry
> > > about it then.
> > 
> > As I understand, you propose to allocate some space in mmap.
> 
> No, sorry if I wasn't very clear. I just mean that you can get away with
> a single kernel managed page per mm, with an emuframe allocated
> per-thread which that thread always uses, since they never nest, which I
> think simplifies the whole thing significantly.
> 
> The allocation could be smarter than that of course in case you have
> thousands of threads and only a subset doing lots of FP branches, but a
> single thread should never need more than one at a time since the new
> signal behaviour effectively makes the delay slot emulation sort of
> atomic from the point of view of usermode, and the kernel knows for sure
> whether BD emulation is in progress from the PC.
> 
> (If there is some other way than signals that I haven't taken into
> account that the emulation could be pre-empted then please let me know!)

Right, look at uprobes, it does exactly all this with a single page.
Slot allocation will block waiting for a free slot when all are in use.

If you need to support nesting, you need to do greedy slot allocation,
which is possible with limited nesting.
--
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/