[Qemu-devel] remark about http://www.freeoszoo.org

[Qemu-devel] remark about http://www.freeoszoo.org

[albi]

hi,

First of all, kudos for developing QEMU! it's cool to play with! :)

I noticed an error at the downloads, when i downloaded reactos-0.2.3.tar.bz2
i found out it's really a tar.gz file and not a tar.bz2, can you change that
? thnx

cya,
albi

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Karl Magdsick]

As a note to anyone planning on uploading QEMU disk images to Free OS
Zoo, Free OS Zoo's suggested way of creating disk images does not (in
the general case) blank out the unused space in the disk image.  As a
result, the image will likely contain parts of deleted files from the
host OS.  This will reduce compressability of the disk images and may
cause the disk images to contian sensitive information, such as
passwords and credit card numbers.

This isn't a problem unless you think you might possibly give the disk
image to someone else in the future.

To prevent this, in the dd command, use if=/dev/zero and change the
count to be the suggested seek value.  Do not specify a seek value. 
This will cause dd to take longer to create a disk image, but it will
zero out the contents of the file, rather than asking the OS to create
a file from whatever garbage is left on disk.

As much as I like your passwords, credit card numbers, and assorted
smutt, I'd rather not download them from Free OS Zoo.


-Karl

On Sat, 2 Oct 2004 15:16:21 +0200, albi <albi@scii.nl> wrote:
> 
> hi,
> 
> First of all, kudos for developing QEMU! it's cool to play with! :)
> 
> I noticed an error at the downloads, when i downloaded reactos-0.2.3.tar.bz2
> i found out it's really a tar.gz file and not a tar.bz2, can you change that
> ? thnx
> 
> cya,
> albi
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Lennert Buytenhek]

On Sun, Oct 03, 2004 at 01:47:00PM -0400, Karl Magdsick wrote:

> To prevent this, in the dd command, use if=/dev/zero and change the
> count to be the suggested seek value.  Do not specify a seek value. 
> This will cause dd to take longer to create a disk image, but it will
> zero out the contents of the file, rather than asking the OS to create
> a file from whatever garbage is left on disk.

You think that "dd if=/dev/null of=blah bs=1024k count=1 seek=1024"
creates a file that can have anything else than just zeroes in it,
hm?

Just try it.  And then please apologise to the freeoszee people.


--L

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Brad Campbell]

Karl Magdsick wrote:
> As a note to anyone planning on uploading QEMU disk images to Free OS
> Zoo, Free OS Zoo's suggested way of creating disk images does not (in
> the general case) blank out the unused space in the disk image.  As a
> result, the image will likely contain parts of deleted files from the
> host OS.  This will reduce compressability of the disk images and may
> cause the disk images to contian sensitive information, such as
> passwords and credit card numbers.
> 
> This isn't a problem unless you think you might possibly give the disk
> image to someone else in the future.
> 

I think perhaps you should go back and do some reading on sparse files, what they are and how they 
work before jumping to such conclusions.

Brad

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Karl Magdsick]

Free OS Zoo suggests using dd with the seek= option in the _specific_
case of Linux, which appears to be safe.  My comment was explicitly a
note of caution in the _general_ case. I did not intend to slander the
suggestions posted on the Free OS Zoo page.  My comments were meant
merely as a word of caution about over-generalizing the suggestions of
the Free OS Zoo people.

Perhaps I should have been more clear about the "in the general case"
part of my statement.  I meant "general" in the sense of making as few
extra assumptions as possible, not in the sense of "common".

Unless I had specific knowledge about sparse file support on my
filesystem and the behavior of fseek, lseek, llseek, etc. seeking past
the end of a file that cannot become sparse on my system, I would not
risk personal information on assumptions about the behavior of my
system.  Documentation of this behavior is spotty at best.  (Solaris
and Linux manpages, as well as the latest edition of Advanced
Programming in the UNIX Environment, implicitly assume that sparse
files are available across the board.)

In the specific case where you are using a filesystem that supports
sparse files (ext2, ext3, ufs, ffs, ntfs, etc.), seeking past the end
of the file is well documented and will create a sparse file, and
everything will be dandy.  HFS+ does not support sparse files, but OS
X zeroes out blocks as the seeks force their allocation on HFS+
partitons.  The latest Debian-testing for x86 will cause seeks past
the end of files on VFAT filesystems to fail, but this is not evident
from the documentation.  Therefore, for 99% of QEMU users, the
suggested method is probably safe.

I hereby apologise to anyone that feels I have over-stated the risks
involved in using dd to seek past the end of a file on arbitrary
filesystems and arbitrary OSes.  In the specific cases of ext2/ext3 on
Linux, NTFS on WinXP (cygwin or CoLinux), and HFS+/UFS on OS X, dd
will most likely behave correctly with the suggested inputs.  (I have
no personal experience with dd on WinXP.)  In the case of vfat
filesystems on Linux, the suggested method will fail in a safe manner,
leaking no information.



Sorry for any confusion,
-Karl


On Sun, 3 Oct 2004 21:21:54 +0200, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Sun, Oct 03, 2004 at 01:47:00PM -0400, Karl Magdsick wrote:
> 
> > To prevent this, in the dd command, use if=/dev/zero and change the
> > count to be the suggested seek value.  Do not specify a seek value.
> > This will cause dd to take longer to create a disk image, but it will
> > zero out the contents of the file, rather than asking the OS to create
> > a file from whatever garbage is left on disk.
> 
> You think that "dd if=/dev/null of=blah bs=1024k count=1 seek=1024"
> creates a file that can have anything else than just zeroes in it,
> hm?
> 
> Just try it.  And then please apologise to the freeoszee people.
> 
> 
> --L

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Lennert Buytenhek]

On Mon, Oct 04, 2004 at 02:50:31AM -0400, Karl Magdsick wrote:

> Free OS Zoo suggests using dd with the seek= option in the _specific_
> case of Linux, which appears to be safe.  My comment was explicitly a
> note of caution in the _general_ case.

Yep.  As well as:

	"[...] the image will likely contain parts of deleted files from
	the host OS."

Just curious, do you have an example of any such system where this
would be the case?  I don't know of any system that doesn't support
sparse files and doesn't pad out the file with zeroes if you
truncate(2) it to be bigger.


cheers,
Lennert

Re: [Qemu-devel] remark about http://www.freeoszoo.org

[Paul Brook]

On Monday 04 October 2004 12:29, Lennert Buytenhek wrote:
> On Mon, Oct 04, 2004 at 02:50:31AM -0400, Karl Magdsick wrote:
> > Free OS Zoo suggests using dd with the seek= option in the _specific_
> > case of Linux, which appears to be safe.  My comment was explicitly a
> > note of caution in the _general_ case.
>
> Yep.  As well as:
>
>  "[...] the image will likely contain parts of deleted files from
>  the host OS."
>
> Just curious, do you have an example of any such system where this
> would be the case?  I don't know of any system that doesn't support
> sparse files and doesn't pad out the file with zeroes if you
> truncate(2) it to be bigger.

I'm fairly sure any half-sane OS will zero the "sparse" bits of a file on 
allocation. IIRC even Windows NT does zero the sparse bits of a file.
Failure to do so would be a rather large security hole, effectively allowing 
unprivileged users to read privileged data.

IMHO the original post is unjustified paranoia, rather than reasonable 
caution.

Paul