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