Date: Fri, 9 Jun 2000 09:07:58 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: arch@freebsd.org Subject: Syscalls and execve Message-ID: <Pine.BSF.4.21.0006090856480.37053-100000@salmon.nlsystems.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006090856480.37053-100000>