From owner-freebsd-arch@FreeBSD.ORG Thu Aug 28 11:14:58 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772291065674; Thu, 28 Aug 2008 11:14:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFBE8FC32; Thu, 28 Aug 2008 11:14:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 62CC946C8A; Thu, 28 Aug 2008 07:14:55 -0400 (EDT) Date: Thu, 28 Aug 2008 12:14:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> Message-ID: References: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Arch , Konstantin Belousov Subject: Re: Kernel decontextualization -- idea and little proof-of-concept X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 11:14:58 -0000 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