[Libguestfs] [PATCH 0/4] Add hivex APIs into the libguestfs API (RHBZ#852394)

[Richard W.M. Jones]

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