From owner-freebsd-net@FreeBSD.ORG Thu Mar 25 05:35:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9943016A4CF; Thu, 25 Mar 2004 05:35:53 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F5943D48; Thu, 25 Mar 2004 05:35:53 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i2PDXfxC052908; Thu, 25 Mar 2004 08:33:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i2PDXfCa052905; Thu, 25 Mar 2004 08:33:41 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 25 Mar 2004 08:33:41 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20040325111235.GY8930@darkness.comp.waw.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@FreeBSD.org Subject: Re: in_pcbbind_setup(), etc. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2004 13:35:53 -0000 On Thu, 25 Mar 2004, Pawel Jakub Dawidek wrote: > +> Prior to FreeBSD 5.x, curproc could be NULL in interrupt context. With > +> the introduction of curthread and the move to interrupt threads, curthread > +> became always non-NULL. However, sometimes the use of curthread may not > +> make sense. :-) I think I'd prefer it if we passed an explicit > +> credential into a number of these situations, which could be NULL if "the > +> system" was requesting a service as opposed to an explicit user process. > +> However, I'm not 100% convinced that is the right approach either. Note > +> that we have some similar "confusions" relating to use of cached > +> credentials in sockets, etc. The whole issue probably needs to be > +> discussed after some detailed analysis, and revisited. > > Ok, I've add few line at start of in_pcbbind_setup(): > > if (td == NULL) > printf("NULL td in %s\n", __func__); We should probably commit a KASSERT(), or perhaps just page fault if td is NULL. > if (td != curthread) > printf("td != curthread in %s\n", __func__); > > And I'm seeing 2nd printf() while mounting NFS file systems. If so, I > think using td->td_ucred in this function isn't safe... Yeah, that sounds fairly dubious. One of the things we've been thinking about for a while on the TrustedBSD Project is adding support for polyinstantiation, which for those who've not bumped into it before, means a virtualization of a service based on security properties. In the case of TCP/IP and UDP/IP, it would mean adding additional matching parameters to the PCB matching process, which currently is based on the address/port pair for the packet and PCB. In particular, adding the label of the packet and label of the PCB. It would also require some changes to the binding mechanism which would require explicit passing of the credential authorizing the bind. So my current leaning is that instead of passing in a thread, we should be passing in a credential reference -- especially as 'td' is only used to reach the credential in the PCB binding routines, not for anything else. Then it becomes the callers responsibility to make sure the reference remains valid and is safe from a locking perspective, which should be a lot easier to do than with a thread reference. How does this sound? It would completely eliminate the issue of "er, which thread is that", which is really an unnecessary issue given that all we're interested in is the credential. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research