Report of my virtual network lab migrated from virtualbox to bhyve

Aryeh Friedman aryeh.friedman at gmail.com
Sat Feb 8 20:14:06 UTC 2014


On Sat, Feb 8, 2014 at 3:01 PM, Adam Vande More <amvandemore at gmail.com>wrote:

>
> On Sat, Feb 8, 2014 at 6:51 AM, Aryeh Friedman <aryeh.friedman at gmail.com>wrote:
>>
>> bhyve blindly read/writes into the middle of the file without consulting
>> the filesystem and thus bypassing any things like sparse fill in.... namely
>> all you gain is a few seconds of startup time (matter of fact I think
>> truncate might use sparse allocation [i.e. attempting to read into the
>> middle with guest OS control will result in potentially seeing host data])
>>
>
> If this is true then there is a *critical* security issue.
>
> Using sparse files isn't to gain performance, it's to conserve disk space.
>  Using md devices backed by sparse images would accomplish this.  If the
> sparsify app works on FreeBSD, then there should be no problem using those
> type of volumes.
>
>
It sounds almost identical to the qcow2 security issue being discussed on
qemu-devel at qemu.org recently.   This might be a *HUGE* win for bhyve then
in considering that it's default format is raw (should ahci-hdd be the
default?).   devel/qemu (not sure about -dev) uses qcow2 as a default and
when playing with it on other OS's I found that it seemed to default to
that also.  It is my understand that most of the open source cloud
platforms use qcow2 as their default also (I remember this from an attempt
to install openstack grizzly last summer... I have not checked havana
though... can any of the freebsd-openstack confirm this?).

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


More information about the freebsd-virtualization mailing list