On Wed, Aug 29, 2012 at 04:15:31PM +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=852394
"libguestfs inspection limits registries to 100 MiB"
On the subject of this limit:
Before the change, we had this arbitrary 100 MiB limit so that we
didn't download arbitrary amounts of data from the guest into /tmp.
This is obviously a good thing, but a customer of ours ran into a
guest which had a large number of software packages installed and had
a > 100 MiB registry hive.
After the change, things are a little bit more complex:
* If you open a hive for reading, hivex mmaps it into the
process map of the daemon. For a normal-sized hive, this
effectively demand-loads the hive from disk as required, and
since the majority of inspection operations hardly touch the
hive, this is potentially more efficient.
For a large (or corrupt/malicious) hive, a 32 bit processor will
naturally limit the amount that can be mmapped to ~ 1 GB and fail
gracefully if it is larger. A 64 bit processor will map just about
any hive, but it's only demand-loaded so that doesn't especially
matter.
* If you open a hive for writing, hivex tries to malloc enough memory
to store a complete copy of the hive, and will fail if there is not
enough memory. It's likely that it doesn't fail gracefully
(because of the implementation of malloc itself) if the hive is
huge. Probably this will crash the daemon or appliance.
Therefore when opening a hive for writing, it's a good idea to check
the size of the hive beforehand to ensure it's reasonable.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top