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
| ||
|
Date: Fri, 27 Jun 2008 13:50:09 -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 Sun, Jun 22, 2008 at 11:11:02AM +0200, Renzo Davoli wrote: > There are three events for a syscall: > START - call notification > CALL - run the SYSCALL > EXIT - return notification. > > I think that it is a non sense to write code for useless cases. > Let us see all the combinations of doing/skipping each one of the three > phases: > > 0- DOSTART - DOCALL - DOEXIT - Standard PTRACE_SYSCALL (new option 0) > 1- DOSTART - DOCALL - SKIPEXIT - PTRACE_VM_SKIPEXIT of my proposal > 2- DOSTART - SKIPCALL - DOEXIT - useless, nothing has changed between > the two notifications > 3- DOSTART - SKIPCALL - SKIPEXIT - PTRACE_VM_SKIPCALL in my proposal > 4- SKIPSTART - DOCALL - DOEXIT - is this useful? (Case 4,see below) > 5- SKIPSTART - DOCALL - SKIPEXIT - simply don't use PTRACE_SYSCALL > 6- SKIPSTART - SKIPCALL - DOEXIT - this is the old PTRACE_SYSEMU (case 6) > 7- SKIPSTART - SKIPCALL - SKIPEXIT - nullify completely the syscalls > (case 7). > > case 4: a vm or debugging monitor receives just the return value of a > syscall. In many architectures it not even possible to read the parameters > of the call (e.g. powerpc where the first argument and the return value > use the same register). This choice must be done a-priori, so without > actually know which will be the next system call. I can see this being useful - this is kind of what strace wants, except that it wouldn't be able to see that a system call is about to sleep. This could be implemented by just stashing any trashed registers off to the side ala x86 orig_eax. > case 6: this makes sense just for applications which virtualize *all* the > system call, current PTRACE_SYSEMU works exactly in this way. > My patch shows that for these applications it does not matter whether the > virtualization takes place before skipping the call or after having just > skipped the call. So PTRACE_VM_SKIPCALL can be used instead. Yup. > case 7: skip the next syscall and give no information about, there is no way > to virtualize or trace what is going on. > Who could be ever interested in an option like this? No one. > It seems that the combinations that really make sense are those skipping > a trailing part of the sequence. > > DOSTART - DOCALL - DOEXIT my option 0 > DOSTART - DOCALL - SKIPEXIT my option PTRACE_VM_SKIPEXIT > DOSTART - SKIPCALL - SKIPEXIT my option PTRACE_VM_SKIPCALL Seems reasonable. In this case, they should be numbered 0, 1, 2 rather than having masks or-ed together. This happens to produce the same numbers, except that 3 is outlawed. > If you think that it is not clear from the tag name that PTRACE_VM_SKIPCALL > implies PTRACE_VM_SKIPEXIT let us change the name in: > PTRACE_VM_SKIPCALL_SKIPEXIT > Maybe the name is quite long, but in this way it is clear what it > does. Maybe. How about PTRACE_VM_TRACESTART? Makes the naming somewhat non-orthogonal, but shorter and descriptive. 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