V_* meta-symbols and locking
jamie at gritton.org
Wed Jun 18 15:56:46 UTC 2008
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
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
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.
> teh man page for vimage(8) says for the chroot parameter:
> 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
More information about the freebsd-virtualization