Allow volatility to be used as a framework (by removing/reducinng global usage)

[GoogleCodeExporter]

Ideally volatility shouldn't be so dependent on a single command line 
configuration option, or more specifically global variables that then don't 
allow two different plugins to be run with different option sets.

This is a (low priority) tracking bug so that we can keep a track of 
discussions and development in the area without having to trawl back through 
lots of IRC discussions.  If this gets enough action, we can create a branch in 
subversion for it.

Original issue reported on code.google.com by mike.auty@gmail.com on 2 Sep 2010 at 12:33

• Merged into: #521

[GoogleCodeExporter]

Here's an initial patch that changes AddressSpace objects to accept both a base 
and config object.  The config object is then used locally internally and can 
be retrieved using get_config().

To allow address spaces to register their own options, I've added a 
staticmethod register_options which is passed a config object which should make 
changes to.  Note, an address space can only add options it requires once when 
it is registered with the address space registry.

This patch still uses the global config object, but it's now set in 
utils.load_as() and passed around to any address spaces that need it.  This 
will need changing to utils.load_as(config) when we come to change plugins to 
accept a config object and/or register their options.

Since a config object should be passed in at one point, it ought to be that 
changes to that config object trickle down to the address spaces/etc that need 
them.

Comments/suggestions/bugs/discussion are more than welcome.  If this style 
(config passed in the constructor and staticmethod for registering options), I 
can start to mock it up for commands as well.

Note, I've already made a slight change in the main so that objects do not 
require config access.  They only used configs to check for write support, and 
that's now always passed to the address space to decide.

Original comment by mike.auty@gmail.com on 2 Sep 2010 at 12:45

[GoogleCodeExporter]

Would've helped if I'd actually attached the patch, sorry for the spam.

Original comment by mike.auty@gmail.com on 2 Sep 2010 at 12:46

Attachments:

• volatility-no-as-config.patch

[GoogleCodeExporter]

This patch has now been applied in the no-globals branch, and further work will 
be posted there.  Any noteworthy or new developments/problems will be posted to 
this bug.

Original comment by mike.auty@gmail.com on 2 Sep 2010 at 4:14

[GoogleCodeExporter]

Ok, the no-globals branch has been converted so that all plugins take a config 
object.  Global configuration options can be registered using a staticmethod 
register_options (just like address spaces), and per-plugin objects are handled 
in __init__ (much like they are now).  Also, address spaces are now passed the 
config of their plugin, rather than using the global one (although this may 
need some test.

Unfortunately, we can't see the full effects until the config object is changed 
from a singleton object to a instance-based one.  At the moment, all the 
internals are class variables, shared between each instance.  This creates some 
interesting difficulties (such as removing options to recreate them in 
inherited plugins).

Unfortunately there's still some global config usage in the case of time zones 
(where it's not clear how to get the config to the object), and "plugins" like 
fileparam that actually just register a global option.

This branch could use scudette love to make the config object per-plugin, and 
then some testing/decisions from people to figure out whether this is a good 
way forward/worth pushing into volatility-1.4.  It is a slight API change for 
plugin developers, but the change is relatively simple to implement (so the 
bulk of plugin code shouldn't require much changing).

This also turned up another interesting issue.  Scanner objects need an initial 
address space to create an object, so that they can check initial sizes of 
certain structures.  When the scanner object is created, it previous made a 
BufferAddressSpace, which got its profile using the global config.  So we need 
to decide whether scanner should require an address space on initialization, or 
whether checks aren't given an address space when they need to initialize.

So basically, at the moment, some plugins are still broken on no-globals, but 
we are quite further forward down the avenue of per-plugin config objects...

Original comment by mike.auty@gmail.com on 3 Sep 2010 at 1:15

[GoogleCodeExporter]

I also forgot to mention, since I figured external people shouldn't be changing 
our configs without our knowing, that the variable should be self._config, 
rather than self.config.  Since config's an object, this doesn't make a great 
deal of different, but this keeps it in line with the address_space stuff.

I'm completely open to options on this one?  I was looking into turning it into 
a property (so that we can make it read-only, although again, since it's an 
object that may not have such a big impact), so any opinions on the matter, 
either way, just let me know and I'll go through and change it...  5:)

Original comment by mike.auty@gmail.com on 3 Sep 2010 at 1:33

[GoogleCodeExporter]

Ok, just did the big merge (although haven't got git merge figured out, so it 
ended up being a delete and move from no-globals after all the changes were 
across).

The state is now that address spaces all have their own self._config (handed to 
them by the plugin that created them) and all plugins also have their own 
self._config (which they can then hand on to address spaces as necessary).  Any 
objects that require a config (such as VolatilityMagic objects), can/do get 
them from self.vm.get_config() getter function.

The global object can't go entirely local quite yet, because there are still 
certain modules that make use of them being global (notably plugins/__init__.py 
for the additional plugin paths, plugins that modify other global commands like 
fileparam, and framework components that require config information such as the 
tzformat).

Original comment by mike.auty@gmail.com on 24 Nov 2010 at 2:55

[GoogleCodeExporter]

Gonna mark this as 3.0 since it sounds like one of the main 3.0 goals. 

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:31

• Added labels: Milestone-3.0.x

[GoogleCodeExporter]

As I've been hitting various issues with the global/sequential nature of 
ConfObject, I was wondering if any thought had been given to using dependency 
injection to reduce plugin reliance on ConfObject (and so aid composability of 
the framework)?

If it would help, I'm willing to do some coding experiments along such lines?

Original comment by carl.pulley on 20 Apr 2013 at 8:19

[GoogleCodeExporter]

Hiya Carl, this is already flagged for volatility 3.0, which will have quite 
significant changes under the hood.  I really wouldn't recommend putting effort 
into fixing the way that volatility 2.2/2.3 does this since it will be 
different in volatility 3, but it's entirely up to you.

Original comment by mike.auty@gmail.com on 20 Apr 2013 at 10:49

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 18 Feb 2015 at 6:51

• Changed state: Duplicate