Date: Thu, 28 Aug 2008 12:14:55 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Attilio Rao <attilio@freebsd.org> Cc: FreeBSD Arch <arch@freebsd.org>, Konstantin Belousov <kib@freebsd.org> Subject: Re: Kernel decontextualization -- idea and little proof-of-concept Message-ID: <alpine.BSF.1.10.0808281211040.98415@fledge.watson.org> In-Reply-To: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> References: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Aug 2008, Attilio Rao wrote:
> Small Q&A about possible concerns:
> Q: Sometimes we need to pass a thread in order to get his credentials,
> how you will handle this?
> A: We will simply get the ucred pointed and will switch the thread
> argument to be a credential
I tend to agree with the approach you are proposing, and have been considering
similar changes for the network stack for much the same reasons. Thre points:
(1) We may need to explicitly pass one or more credentials in places where we
don't currently do so. This is certainly true in the network stack, and
similar considerations in VFS wouldn't surprise me. Most frequently, this
construct is used when work occurs in an asynchronous context from the
requesting thread and use of the original authorizing credential is
required.
(2) Keep a careful eye out for cases where an implicit use of the passed
thread is to establish context for copyin(9). You might argue that
copyin(9) should accept an address space or thread argument and then
assert that it is the current one...
(3) Take a look at the on-going virtualization work, as we may want to apply
the same virtualization techniques to VFS in the future, in which case
we'll need to make sure that the approaches are compatible.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808281211040.98415>