linux-kernel - PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in

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:	Sun, 2 Dec 2012 20:30:58 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Amnon Shiloh <u3557@...o.sublimeip.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Pedro Alves <palves@...hat.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in_kernelspace: fix
	the range check)

Amnon, sorry for delay...

On 11/26, Amnon Shiloh wrote:
>
> > Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't
> > change emulate_vsyscall() to respect PTRACE_SYSCALL and report
> > TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
> > http://marc.info/?l=linux-kernel&m=135343635523715 ?
> >
> > Oleg.
> >
>
> For my own application, I would be happy with this.

OK, good.

> But I suspect it might break current versions of "strace",
> ...
> I think it COULD work, but not based on PTRACE_SYSCALL
> (or PTRACE_SYSEMU) alone.  A new ptrace option will be needed, saying:
> "Yes, I am aware of TRAP_VSYSCALL and I know how to handle it."

Yes, that is why I said this needs the new option.

However. Of course it would be nice to avoid the new option. IMO it
would be better to do nothing ;) vsyscall is deprecated, and EMULATE
is x86-specific.


May be we could simply do something like the patch below? (Just in
case, this hack is only for illustration, it is not complete).

If the tracer does PTRACE_SYSCALL the tracee reports syscall exit
_after_ gettimeofday/etc. The tracer can look at regs->orig_ax == -1
and detect that this is not syscall but vsyscall, it can look at
regs->ip then (not with the patch below).

Denys, Jan, Pedro. Do you think this change can break/confuse
gdb/strace ?


> While for my own application, just fixing the range-check in
> arch_check_bp_in_kernelspace will do,

You forgot again that EMULATE does not execute the code in the
vsyscall page.

Oleg.

--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -186,6 +186,8 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size)
 	}
 }
 
+#include <linux/tracehook.h>
+
 bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 {
 	struct task_struct *tsk;
@@ -312,6 +314,8 @@ do_ret:
 	regs->ip = caller;
 	regs->sp += 8;
 done:
+	if (test_thread_flag(TIF_SYSCALL_TRACE))
+		ptrace_report_syscall(regs);
 	return true;
 
 sigsegv:

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