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:	Tue, 17 Jun 2008 12:25:11 -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 Mon, Jun 16, 2008 at 09:58:04AM +0200, Renzo Davoli wrote:
> Summary of the solution:
> Use tags in the "addr" parameter of existing
> PTRACE_SYSCALL/PTRACE_SINGLESTEP/PTRACE_CONT/PTRACE_BLOCKSTEP calls
> to skip the current call (PTRACE_VM_SKIPCALL) or skip the second upcall to 
> the VM/debugger after the syscall execution (PTRACE_VM_SKIPEXIT).

On the whole, I'm in favor of generalizing ptrace, especially if it
also simplifies the interface and code.  Some notes below...

> I already proposed some time ago a different tag: PTRACE_SYSVM 
> (and I maintain a patch for it) where:
> ptrace(PTRACE_SYSVM, pid, XXX, 0)
> 1* is the same as PTRACE_SYSCALL when XXX==0,
> 2* skips the call (and stops before entering the next syscall) when
>   PTRACE_VM_SKIPCALL | PTRACE_VM_SKIPEXIT

There's a symmetry implied in the PTRACE_VM_SKIPCALL and
PTRACE_VM_SKIPEXIT names which doesn't exist in reality.  SKIPEXIT (as
you note later) merely omits the notification on system call return.
SKIPCALL keeps the notification, but omits the system call execution,
so the effects are very different from each other.

I think this is just a naming issue - we don't want the names to fake
people into assuming things which aren't true.

> SYSVM can be used also for partial virtual machines (some syscall gets
> virtualized and some others do not), like our umview.

BTW, if performance is the issue here (and I don't see any other
compelling reasons for it), there are other possibilities which
provide much better performance.  Any PTRACE_* variant will have at
least one notification.  While there is a noticable gain over two
notifications, that's marginal compared to no notifications at all.
If you know ahead of time what system calls you want to trace, a
system call tracing mask lets you avoid those notifications totally.

I wrote up a patch a couple of years ago -
	http://marc.info/?l=user-mode-linux-devel&m=114495242202954&w=2
but the interface implemented there isn't very good.

    		  	      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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ