pcp
[Top] [All Lists]

Re: Checking PCP archives - RFC

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: Checking PCP archives - RFC
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 22 May 2013 10:00:41 +1000
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mfvxgl3r3.fsf@xxxxxxxx>
References: <519AC94B.9020904@xxxxxxxxxxxxxxxx> <y0mfvxgl3r3.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
On 22/05/13 02:03, Frank Ch. Eigler wrote:

For #3, have you considered writing a general fuzzer?

I considered it, but only briefly ... I think there is more bang for buck in making bad archives in a structured-directed way, rather than changing random bytes in an archive (or did you have some more sophisticated sort of fuzzer in mind?).

[...]  So, in the spirit of the original Unix filesystem, I'm
proposing an ncheck/icheck (none of you're whimpy fsck in those
days) tool, pmlogcheck. [...]

Have you considered whether this sort of checking could be added to
libpcp pmNewContext, activated by environment variable or somesuch, as
opposed to a separate tool?

Given there are possibly millions of PCP archives in the existence, and the number of pathologically broken ones is (as far as I know) very small (less than 10?), I'm not convinced that the overhead (pmlogcheck is not going to be cheap in terms of resource demand) is warranted for every invocation of pmNewContext with PM_CONTEXT_ARCHIVE, but conditionally based on an environment variable (or maybe even a type modifier to pmNewContext, in the flavor of PM_CTXFLAG_SECURE) is certainly feasible. I'll add this to the TODO list.

I still think pmlogcheck needs to be a separate tool, especially if it grows into something that can repair some classes of corruption, as per my earlier mail exchange with Nathan.

<Prev in Thread] Current Thread [Next in Thread>