From owner-freebsd-arch Thu Oct 4 10:27:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B283537B405; Thu, 4 Oct 2001 10:27:02 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA52914; Thu, 4 Oct 2001 19:27:01 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Removing ptrace(2)'s dependency on procfs(5) From: Dag-Erling Smorgrav Date: 04 Oct 2001 19:27:00 +0200 Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Bcc:ed to -security, please followup on -arch] The ptrace(2) syscall, which is mainly used by gdb(1), implements some of its functionality by faking up a struct uio and making calls into the guts of procfs(5). This is why four of the source files that make up procfs(5) are listed as "standard" rather than as "optional procfs" in src/sys/conf/files. The funny thing is that there's no reason for the ptrace(2) code to call any procfs(5) code, since the functions it calls are actually (mostly) wrappers around MD code, with some extra error checking. The errors they check for are of the kind that Can't Happen[tm] when these wrappers are called from ptrace(2) because ptrace(2) already checks for them before calling the procfs(5) code. For instance, all procfs_domem() does is check that uio->uio_resid is non-zero (ptrace() sets it to sizeof(int)) and that the requesting process is allowed to debug the target process (already checked by ptrace()), and then pass its arguments unmodified to procfs_rwmem(). What I propose to do is: - move procfs_rwmem() from src/sys/fs/procfs/procfs_mem.c into src/sys/kern/sys_process.c or some other convenient location where both ptrace(2) and procfs(5) can access it (and also move its prototype to a convenient header file). - rewrite the remaining cases (PT_{GET,SET}{,DB,FP}REGS) to call procfs_{read,write}_regs() (which is implemented in each port's procfs_machdep.c) directly, instead of calling procfs_do*(). - make the permission checks at the top of ptrace(2) slightly more aggressive (immediately return EINVAL if the target process is a system process; immediately return EPERM if p_candebug() returns non-zero and an operation other that PT_TRACE_ME was requested). This will slightly reduce the size (and speed up the build) of a procfs(5)-less kernel. I would also like to implement a kernel option named NO_DEBUGGING (or something similar) which replaces ptrace(2) and the MD parts of procfs(5) with stubs that simply return EINVAL or EPERM, thus making it impossible to use gdb(1), truss(1) and similar tools; I will also change procfs(5) to not list debugging-related files (ctl, regs etc.) when loaded by a kernel that was built with NO_DEBUGGING. Comments? Flames? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message