Date: Fri, 9 Jun 2000 01:50:31 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Doug Rabson <dfr@nlsystems.com> Cc: arch@FreeBSD.ORG Subject: Re: Syscalls and execve Message-ID: <200006090850.BAA10749@apollo.backplane.com> References: <Pine.BSF.4.21.0006090856480.37053-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
I would say "no" for exec... there are certainly security
implications, but I would worry more about starting a new program
with inconsistent state. It's not a good idea even if the state
is supposed to be unused.
Why not have the new exec()'d process, when it gets the cpu in supervisor
mode, clear the registers in supervisor mode before returning
to user mode? e.g. near the end of kern/kern_exec.c's execve().
(or somewhere similar). Then at least the 'garbage' will be more
like what you see on return from a syscall rather then something
inherited from another process.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200006090850.BAA10749>