linux-kernel - [PATCH 00/10] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150504124835.GA22462@redhat.com>
Date:	Mon, 4 May 2015 14:48:35 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Ananth N 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 00/10] uprobes: longjmp fixes

Hello.

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 on x86:
it assumes 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.

Jan, David, Pratyush, Ananth, do you think your architecure can reuse
the hacks/hooks added by this series and do something like x86 does?
If not, we will probably need "plan B" mentioned in 08/10, but I'd
like to avoid this if possible. Or any other thoughts?

Oleg.

 arch/arm/include/asm/uprobes.h     |    3 +
 arch/arm/probes/uprobes/core.c     |    3 +-
 arch/powerpc/include/asm/uprobes.h |    3 +
 arch/powerpc/kernel/uprobes.c      |    3 +-
 arch/s390/include/asm/uprobes.h    |    3 +
 arch/s390/kernel/uprobes.c         |    3 +-
 arch/x86/include/asm/uprobes.h     |    4 +
 arch/x86/kernel/uprobes.c          |   15 +++-
 include/linux/uprobes.h            |    5 +-
 kernel/events/uprobes.c            |  170 +++++++++++++++++++++---------------
 10 files changed, 136 insertions(+), 76 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/