Date: Wed, 18 Jun 2008 09:19:18 -0700 From: Julian Elischer <julian@elischer.org> To: James Gritton <jamie@gritton.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking Message-ID: <48593586.9040600@elischer.org> In-Reply-To: <48593036.60502@gritton.org> References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48593586.9040600>