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: Mon, 30 Apr 2007 10:33:31 +0100 From: Russell King <rmk+lkml@....linux.org.uk> To: Christoph Hellwig <hch@....de> Cc: Christoph Hellwig <hch@...radead.org>, Roland McGrath <roland@...hat.com>, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org Subject: Re: utrace comments On Mon, Apr 30, 2007 at 11:22:00AM +0200, Christoph Hellwig wrote: > On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote: > > Roland's idea of single-stepping is that it *must* be supported by > > hardware for utrace to use it. There are a number of architectures > > which can only do single-stepping by modifying the text of the > > program being single stepped. ARM is one such example. > > > > As such, even when utrace is complete, some architectures will never > > support in-kernel single step with utrace. I believe Roland's idea > > is to have single step supported on these via some vapourware userspace > > library. > > Does the current arm ptrace code support single stepping in kernelspace? > If yes we absolutely need to continue to support it. single stepping of user space code via standard ptrace calls, yes. > > I'd also like to see utrace become *optional* > > for architectures to support, rather than as it currently stands as > > a *mandatory* requirement when merged. > > No way we'd keep both the old ptrace mess and utrace in the same tree. Given the stated arguments from yourself and Roland, that only leaves one solution to that. I have no real problem with a decision being made to drop kernel-based single stepping _provided_ we have some replacement strategy in place and readily available. At the moment I've not seen such a strategy. I'm not sure if Roland's expecting architecture maintainers to create such a strategy themselves - which would probably turn out to being far worse since you could end up with different implementations for each architecture. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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