Re: Plan C (was Re: Plan B for fixing 5.8.2 binary API)
On Sat, Oct 18, 2003 at 11:09:24AM -0700, Stas Bekman wrote:
> Nicholas Clark wrote:
> >>Something like this? Only with the rough edges smoothed out?
> >
> >
> >>Currently only in blead.
> >
> >
> >Now merged into maint. If it doesn't work it comes out :-)
> >[But it does cope with the attack on http://www.cs.rice.edu/~scrosby/hash/
> >as well as 5.8.1]
>
> Nick, what's your definition of "doesn't work"? This change will affect
> run-time only in certain circumstances, which I'd guess no application has
> tests for. Won't any application that caches the PERL_HASH value now break
> if the rehashing alg tells perl to rehash the key, so the hash entry lookup
> will fail? e.g. mod_perl 2.0 caches PERL_HASH value for all perl callback
I believe not, if it comes in through the API in hv.c, because all the
hash lookup and store functions check the flag on that hash - if it's using
custom keys they discard any passed in hash values. This discard may seem
like a slowdown at first sight, but given that it's for the case where
the hash has degraded into a linear search of a linked list, it ought to
be faster. (Certainly it is faster on the attack data from the paper's
website, but so is 5.8.1)
> GVs it's configured to run, if perl rehashes those values, mod_perl will
> break as it no longer will be able to find those GVs.
How does mod perl find those GVs? Via hv.c calls, or by directly scanning
the HV structure?
> Also, how does it affect the runtime which relies on the PERL_HASH_SEED env
> var to reproduce the exact previous execution? If the rehashing kicks in,
> will it always rehash to the same values?
It's using the hash seed to do the rehashing (with the rehashing using
the exact same algorithm as 5.8.1 is using all the time)
Given that both the 5.8.0 and 5.8.1 algorithms are deterministic, I think
that it should be utterly repeatable if the seed is fixed (or as repeatable
as 5.8.0 and 5.8.1 currently are) but I'm only arm waving.
> Also I suppose we need to replace all occurences of PL_hash_seed(_set)?
> with the 'PL_new_' prefix in mod_perl 2.0. I guess I'll wait till the dust
> settles down. In any case I can't commit the fix since we still have perl's
> SUBVERSION==1 :(
OK. Yes. If we're going for release than this will get bumped soon.
(and modperl not working is a showstopper, so it's not going to get
released until you're happy)
Nicholas Clark
Reply to: