linux-kernel - Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and add useful features for VM

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080618164942.GC8225@c2.user-mode-linux.org>
Date:	Wed, 18 Jun 2008 12:49:42 -0400
From:	Jeff Dike <jdike@...toit.com>
To:	Renzo Davoli <renzo@...unibo.it>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and
	add useful features for VM

On Tue, Jun 17, 2008 at 09:08:31PM +0200, Renzo Davoli wrote:
> 0 -> do the syscall and notify after it

To be more precise - 
	do the call notification, do the syscall, and do the return notification
> PTRACE_VM_SKIPEXIT -> do the syscall and do not notify after it
	don't do the return notification
> PTRACE_VM_SKIPCALL -> skip everything.
	don't do the syscall or return notification

Looking at things this way, it seems like you might want three flags,
since the asymmetry is caused by two things being bundled into
SKIPCALL.

If you have
	PTRACE_VM_SKIPEXIT - skip the return notification
	PTRACE_VM_SKIPCALL - skip the syscall
	PTRACE_VM_SKIPSTART - skip the call notification
this makes the meaning make more sense to me.

The downside of this is that you end up at least one combination that
doesn't make too much sense, like PTRACE_VM_SKIPCALL (do both
notifications even though nothing could have changed in between).

> umview (and now kmview using a kernel module based on utrace) decides if
> a syscall must be virtualized or not depending on the value of its
> arguments, not on the syscall number. With "system call" I mean "call of
> a system call", a "system call call";-)

OK, if you're looking at the arguments in order to decide what to do,
then you can't just mask out the notifications.

     	       	    Jeff

-- 
Work email - jdike at linux dot intel dot 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/