linux-kernel - [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-next>] [day] [month] [year] [list]

Date:	Tue, 7 Jul 2015 03:22:10 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	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>,
	Pratyush Anand <panand@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH v2 00/11] uprobes: longjmp fixes

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/