From owner-freebsd-arch Sat Jun 10 1:35:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id D16C737B74A for ; Sat, 10 Jun 2000 01:34:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 130gj7-000Dz0-0C; Sat, 10 Jun 2000 08:34:47 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA96653; Sat, 10 Jun 2000 09:35:11 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 10 Jun 2000 09:39:06 +0100 (BST) From: Doug Rabson To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Syscalls and execve In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jun 2000, Bruce Evans wrote: > On Fri, 9 Jun 2000, Doug Rabson wrote: > > > ... > > This worked fairly well but there is a question in my mind about > > execve(). The MD function setregs() (very badly misnamed, should probably > > be called cpu_exec() or something similar) tries to arrange for the new > > image to start with all registers set to zero. It does this by zeroing the > > trapframe and assuming that the syscall return will reload all the > > registers. Optimising the syscall path means that the new image will start > > with random values in most of the registers. > > > > Is this acceptable behaviour for exec? Are there any security implications > > for 'leaking' the values which the kernel left in the temporary registers > > on syscall exit (both regular syscalls and execve)? One possibility is to > > explicitly zero the temporaries on syscall exit, which would be faster > > than reloading them from the trapframe. > > There are minor security implementations. The registers might contain > part of a password string or some other secret data, although this is > unlikely and we probably have several lonstanding leaks of this kind > from copying out partially filled structs. > > Not saving the registers in a consistent place for syscalls causes > problems with procfs, ptrace and debuggers. /proc/regs, ptrace() and > accessing registers in the "u area" using ptrace() now work for > processes in the kernel, independently of how they entered the kernel. > In FreeBSD-1.0, the registers were saved in a slightly different place > for syscalls vs for traps, and everything that accessed them had to > know about this complication in order to find them. If you don't save > the registers on syscall entry, then they will be too hard to find. The trapframe which is created for syscall is identical to the trapframe for exceptions and interrupts, its just not fully populated with register values. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message