V_* meta-symbols and locking

Julian Elischer julian at elischer.org
Wed Jun 18 16:19:13 UTC 2008

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

More information about the freebsd-virtualization mailing list