Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jun 2000 09:39:06 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Syscalls and execve
Message-ID:  <Pine.BSF.4.21.0006100938120.68954-100000@salmon.nlsystems.com>
In-Reply-To: <Pine.BSF.4.21.0006092133050.2249-100000@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006100938120.68954-100000>