Date: Fri, 9 Jun 2000 22:18:45 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Doug Rabson <dfr@nlsystems.com> Cc: arch@FreeBSD.ORG Subject: Re: Syscalls and execve Message-ID: <Pine.BSF.4.21.0006092133050.2249-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0006090856480.37053-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce 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.0006092133050.2249-100000>