From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 16:19:12 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6964106564A for ; Wed, 18 Jun 2008 16:19:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id B6D128FC17 for ; Wed, 18 Jun 2008 16:19:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6F0592425; Wed, 18 Jun 2008 09:19:12 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 29CA62D6010; Wed, 18 Jun 2008 09:19:12 -0700 (PDT) Message-ID: <48593586.9040600@elischer.org> Date: Wed, 18 Jun 2008 09:19:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: James Gritton References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> In-Reply-To: <48593036.60502@gritton.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:19:13 -0000 James Gritton wrote: > Julian Elischer wrote: > > > I'm not sure there is much of a problem because the hostname > associated with a virtual machine is a fixed array of bytes. > > > > it is true that one might be able (though unlikely) to get half of > one hostname and half of another but you will never get invalid memory.. > > > > I think that the only readers of the hostname in a vm are processes > in that VM so the VM is not going anywhere and thus the hostname is not > going anywhere.. > > This is true of current jail code, and of vimage. But one of the > points made in the developer summit was that a jail should be able to > virtualize some things and not others. The was really meant about > modules, but it made sense to me that there should also be the option > not to virtualize the non-module bits, i.e. perhaps have a jail that > only had the vnet stuff but kept, for example, the same hostname as > its parent. And I don't mean just inheriting the current hostname, > but making it totally non-virtual so any change to the parent is > reflected. since vimage in hierarchical, and all hostnames are virualised, then the hostname you use is either yours or that of a parent vimage. either way, since you can not remove a vimage while it has children vimages, the logic still applies. > > I'm implementing this by replacing that fixed array with a pointer > that may well be freed. That makes the concurrency issues less > trivial than just the possibility of copying part of one hostname and > not part of another. Now perhaps it would be better to keep the fixed > array, making reading the virtual hostname safe, and complicating the > setting issue (I'd have to set potentially multiple jail records). > This makes sense, as setting is much less common, and is in line with > a similar strategy I have for the securelevel. Even with that though, > the mechanism is in place for safely reading a hostname (i.e. > getcredhostname) and is just not universally used. Might as well > clean that up. well if you want to do that then that is a separate thing but the reason is not because of what vimage is doing with hostname :-) > > > > the man page for vimage(8) says for the chroot parameter: > > > > chroot > > Set the chroot directory for the virtual image. All new processes > > spawned into the target virtual image using the vimage command > > will be initially chrooted to that directory. This parameter can > > be changed only when no processes are running within the target > > virtual image. Note that it is not required to have a chrooted > > environment for a virtual image operate, which is also the > > default behavior. > > > > so the croot is fixed unless there is no-one using it. > > That's a good idea - more flexible than my current strategy of only > allowing setting the path on jail creation, but still not messing up > current jails. And I can continue to ignore the locking implications > of rootvnode. Note that one could also read "or children images" I think in some of these checks.. > > - Jamie