From owner-freebsd-arch Fri Jun 9 1:35:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id BF6F637C260 for ; Fri, 9 Jun 2000 01:35:04 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 130KFr-0009a7-0K for arch@freebsd.org; Fri, 9 Jun 2000 08:35:03 +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 JAA84560 for ; Fri, 9 Jun 2000 09:04:22 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 9 Jun 2000 09:07:58 +0100 (BST) From: Doug Rabson To: arch@freebsd.org Subject: Syscalls and execve 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 I was experimenting the other day optimising the return path for syscall on the alpha. The current code treats syscall return the same as any other exception (restoring *all* registers, making extra checks for returning to user mode etc). This is extra bogus since the syscall entry point rightly doesn't bother to save the values of any temporary registers so on return, those temporaries will be loaded with whatever was lying around on the kernel stack. I decided to streamline the syscall exit by knowing that it will be returning to user mode and the ipl will be zero. Also there is not much point in restoring temporaries since the caller should only expect it to preserve $s0-$6. 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. -- 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