linux-kernel - Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ]

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]

Message-ID: <4B59F032.2060801@redhat.com>
Date:	Fri, 22 Jan 2010 13:36:34 -0500
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel <utrace-devel@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Avi Kivity <avi@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Mel Gorman <mel@....ul.ie>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments
 and actions to be taken ]

Peter Zijlstra wrote:
> On Fri, 2010-01-22 at 12:32 +0530, Srikar Dronamraju wrote:
> 
>> 2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection
>> Rings.
>> 	XOL VMA is an additional process address vma.  This is
>> 	opposition to add an additional vma without user actually
>> 	requesting for the same.
>>
>> 	XOL vma and single stepping inline are the two architecture
>> 	independent implementations. While other implementations are
>> 	more architecture specific. Single stepping inline wouldnt go
>> 	well with multithreaded process.
>>
>> 	Even though XOL vma has its own issues, we will go with it since
>> 	other implementations seem to have more complications.
>>
>> 	we would look forward to implementing boosters later. 
>> 	Later on, if we come across another techniques with lesser
>> 	side-effects than the XOL vma, we would switch to using them.
> 
> How about modifying glibc to reserve like 64 bytes on the TLS structure
> it has and storing the ins and possible boost jmp there? Since each
> thread can only have a single trap at any one time that should be
> enough.

Hmm, it is a good idea. Well, we'll have a copy of original insn
in kernel, but it could be simpler than managing XOL vma. :-)

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

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