volatility does't make a check on the value passed to --profile

[GoogleCodeExporter]

The code currently doesn't sanity check the value passed to --profile and if a 
valid profile isn't passed, it keeps running and eventually exits with an error 
about invalid address spaces, which to most people will be extremely confusing 
and non-obvious 

A better solution would be for the value to be checked and error out with a 
message about the invalid profile

Original issue reported on code.google.com by atc...@gmail.com on 23 Sep 2010 at 12:43

[GoogleCodeExporter]

Yep, I'm thinking of making the add_option into either a choice, or a callback 
that checks the profile's in the list.  That should stop the problem long 
before anything else gets loaded up...

Original comment by mike.auty@gmail.com on 23 Sep 2010 at 1:06

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 23 Sep 2010 at 1:06

[GoogleCodeExporter]

Alternatively we could make the profile loading call die if the profile is 
invalid. This should stop users from specifying profiles which are not valid.

Original comment by scude...@google.com on 23 Sep 2010 at 7:02

[GoogleCodeExporter]

If we do that, it'll still run through each address space trying a duff 
profile, which is why I was intending to only do the one test at the time the 
config option was set.  I'll see if I can mock something up in the next 45 
minutes...  5:)

Original comment by mike.auty@gmail.com on 23 Sep 2010 at 7:19

[GoogleCodeExporter]

Ok, so here's two different patches that both individually solve the problem.  
The first one is call back, so that when the option gets parsed, we can check 
if it's valid or not.  That works fine, but relies on the callback being called 
at some point *after* registry.PROFILES has been populated.  Also, there does 
seem to be a convenience function for listing the names of profiles 
(registry.PROFILES.class_names seems empty even when registry.PROFILES is 
full).  So it works, but it feels slightly shaky (there's several runs of the 
callback where registry.PROFILES is empty and nothing happens).

The second patch raises an address space error that clearly states the profile 
is invalid (whereas previously it was just an unspecified exception that was 
raised).  This one works absolutely fine, but may change depending on the 
no-globals work.  This also wastes a little time because it runs through all 
the address spaces with a known bad profile, rather than exiting as soon as the 
bad profile is detected.  This might prove interesting/useful is we someday 
have profiles that are address space specific...

So the question is, which is the better approach?

Original comment by mike.auty@gmail.com on 23 Sep 2010 at 8:37

Attachments:

• volatility-profiles-patch1.patch
• volatility-profiles-patch2.patch

[GoogleCodeExporter]

Ok, we decided to apply both, so that externally defined configs (ones that 
don't call the callback function) still fail properly when the address spaces 
are loaded.  This is fixed in r456.

Original comment by mike.auty@gmail.com on 23 Sep 2010 at 9:49

• Changed state: Fixed