develooper Front page | perl.perl5.porters | Postings from October 2003

Re: 5.8.2-RC1 and mp2

Thread Previous | Thread Next
Stas Bekman
October 30, 2003 12:20
Re: 5.8.2-RC1 and mp2
Message ID:
Nicholas Clark wrote:
> On Thu, Oct 30, 2003 at 01:37:27AM -0800, Stas Bekman wrote:
>>Nicholas Clark wrote:
>>>HE *
>>>Perl_hv_fetch_ent(pTHX_ HV *hv, SV *keysv, I32 lval, register U32 hash)
>>>   ...
>>>   if (HvREHASH(hv)) {
>>>	PERL_HASH_INTERNAL(hash, key, klen);
>>>	/* Yes, you do need this even though you are not "storing" because
>>>	   you can flip the flags below if doing an lval lookup.  (And that
>>>	   was put in to give the semantics Andreas was expecting.)  */
>>>	flags |= HVhek_REHASH;
>>>   } else if (!hash) {
>>>	PERL_HASH(hash, key, klen);
>>>   }
>>>hv_fetch_ent knows how to ignore the passed in hash value.
>>>(But the thing I was worrying about some days ago appears to have come
>>>to pass) - mod_perl is then storing the hash value from the returned HE *
>>That's exactly what I was repeatedly asking. Whether it'll ignore that 
>>value once or all the time, once the attack is detected. Earlier you said 
>>once, now I understand that only for the first time.
> No. Either you are misunderstanding me, or I am misunderstanding you.
> All hv.c functions ignore a passed in hash value every time when HvREHASH()
> is true. And HvREHASH() is true on any hash that has switched to randomised
> hashing because of pathological data.

And it remains true from then on, right?

> Please look at the source of hv_fetch_ent in hv.c to see the logic, if my
> explanation is failing to make sense.

I think I do get it now.

>>>2: Not using temporaries, but storing both real and rehashed HE* in
>>>  hashes "under attack"
>>>  (not quite sure how - I can see a good way to hang the data of the
>>>   existing structures. Not sure how much extra data this represents,
>>>   either)
>>And it makes things too complex, besides wasted memory and some extra CPU 
> I can see a way to do it that may actually help.
> (Hang a pointer to a shared HEK in the hash key beyond the flag byte.
> Have to copy it out as it's not aligned.
> The benefit is that the linked lists stay the same length, and the unshared
> key can use a pointer into the shared string table. hash routines are
> comparing pointers first, and if they match skipping the memcmp.
> This may actually use less memory than the current implementation)

What about CPU?

>>At the moment I tend to think that exempting GVs from rehashing is the 
>>safest approach to start with. Though someone will now say: "what if 
>>external source which is not under control of the developer is used to 
>>create GVs?"
> Except that the GVs call the regular hash functions, and I'm not sure
> how to make the hash functions aware that it's a GV.

Make GVs call special hash functions?

> After I've eaten I'll have proper look at the modperl source.

Cool. Just be aware that the cvs version somehow works because it does the 
5.8.1 workaround for 5.8.2 too. You need to rip it off with:

Index: src/modules/perl/mod_perl.c
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.201
diff -u -r1.201 mod_perl.c
--- src/modules/perl/mod_perl.c 23 Oct 2003 05:57:46 -0000      1.201
+++ src/modules/perl/mod_perl.c 30 Oct 2003 20:17:29 -0000
@@ -9,8 +9,7 @@
  #define MP_IS_STARTING    (MP_init_status == 1 ? 1 : 0)
  #define MP_IS_RUNNING     (MP_init_status == 2 ? 1 : 0)

-#if !(PERL_REVISION == 5 && ( PERL_VERSION < 8 || \
-    (PERL_VERSION == 8 && PERL_SUBVERSION == 0))) && \
      (defined(USE_HASH_SEED) || defined(USE_HASH_SEED_EXPLICIT))

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About