linux-kernel - Re: [PATCH v2 00/11] uprobes: longjmp fixes

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 Jul 2015 17:31:04 +0530
From:	Pratyush Anand <panand@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Ananth Mavinakayanahalli <ananth@...ibm.com>,
	Anton Arapov <arapov@...il.com>,
	David Long <dave.long@...aro.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Jan Willeke <willeke@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Mark Wielaard <mjw@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/11] uprobes: longjmp fixes

Hi Oleg,

Thanks a lot for the patches.
I did corresponding changes [1] for arch_uretprobe_is_alive on top of
my ARM64 RFC V2 [2] + these patches and found that longjump tests are working.

So for the series's common code

Tested-by: Pratyush Anand <panand@...hat.com>

~Pratyush

[1] https://github.com/pratyushanand/linux/commit/880df93e2dac48f620069fffb16d551e96681774
[2] http://thread.gmane.org/gmane.linux.kernel/1979016

On 07/07/2015:03:22:10 AM, Oleg Nesterov wrote:
> Sorry for delay,
> 
> Currently ret-probes can't work (the application will likely crash)
> if the probed function does not return, and this is even documented
> in handle_trampoline().
> 
> This series tries to make the first step to fix the problem, assuming
> that the probed functions use the same stack.
> 
> TODO: sigaltstack() can obviously break this assumption.
> 
> NOTE: I don't think it is possible to make this logic 100% correct,
> the user-space can do everything with its stack. For example, the
> application can do longjmp-like tricks to implement the coroutines,
> the kernel can do nothing in this case. The application (or debugger)
> should cooperate somehow to let the kernel know whats going on.
> 
> v2, based on disccsussion with Srikar and Pratyush:
> 
> 	1-5:  Unchanged, I preserved the acks from Srikar.
> 
> 	6-11: The only essential change is that we do not add the
> 	      (ugly) arch_uretprobe, we just export return_instance
> 	      to arch/.
> 
> 	      This means that we do not need to touch the !x86 code,
> 	      and return_instance->stack can be initialized by the
> 	      generic code.
> 
> 	      Srikar, I hope you can ack v2 too.
> 
> 	10/11: New. As Pratyush pointed out "bool on_call" is too
> 	       limited.
> 
> Plus v2 fixes the problem mentioned in "self nack" email, we must
> not do cleanup_return_instances() after prepare_uretprobe() checks
> chained && utask->return_instances != NULL.
> 
> Oleg.
> 
>  arch/x86/kernel/uprobes.c |    9 ++
>  include/linux/uprobes.h   |   17 ++++
>  kernel/events/uprobes.c   |  184 +++++++++++++++++++++++++--------------------
>  3 files changed, 128 insertions(+), 82 deletions(-)
--
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/