You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Ralf S. Engelschall" <rs...@engelschall.com> on 1999/01/07 09:18:32 UTC

Re: cvs commit: apache-1.3/src/include ap_mmn.h http_config.h

In article <19...@hyperreal.org> you wrote:
> coar        99/01/06 11:14:52

>   Modified:    src      CHANGES
>                src/include ap_mmn.h http_config.h
>   Log:
>       If we tried to check the version number of a module compiled
>       before 1 January 1999, we'd be looking in the wrong places
>       for the filename and version numbers because the magic cookie
>       insertion changed their offsets.  This fixes that, at the cost
>       of making any modules compiled between 1 January 1999 and 6 January
>       1999 unreadable.  Balancing a span of five days against six
>       months makes this seem reasonable.

When you move the magic cookie to an offset different from 0 this is
problematic IMHO. That's why the cookie is at offset 0: because when mod_so
loads a module it gets the symbol for the module structure. The most harmless
test to check whether it's really a module is to check the integer value at
the address of this symbol. When the file is garbled it could be that the
offset is perhaps already out of memory bounds.  So, I think the cookie should
be at offset 0. Your problem is just a bootstrapping problem, i.e.  you tried
to load older modules without recompiling, right?

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: cvs commit: apache-1.3/src/include ap_mmn.h http_config.h

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ralf S. Engelschall wrote:
> 
> When you move the magic cookie to an offset different from 0 this is
> problematic IMHO.

MHO differs.

>                                                             The most harmless
> test to check whether it's really a module is to check the integer value at
> the address of this symbol.

Moving the cookie down a few bytes maintains binary compatibility
with 1.3.3 and 1.3.2.

>                             When the file is garbled it could be that the
> offset is perhaps already out of memory bounds.  So, I think the cookie should
> be at offset 0.

The cookie moved roughly 24 bytes.  I think the chances of that
putting it out of bounds are fairly slim.

>                 Your problem is just a bootstrapping problem, i.e.  you tried
> to load older modules without recompiling, right?

One of the reasons for having this stuff in the structure at
all is so we can detect compatibility with precompiled modules,
such as those for which the user doesn't have source.  If we
don't maintain the structure in a compatible manner, what's the
point?  The change back in August broke compatibility with modules
compiled earlier, by sticking the MINOR value into the
middle of the STANDARD_MODULE_STUFF rather than at the end.
(I couldn't participate in that discussion; my mail was
down for six weeks.  There's probably a reason I don't
know for it being done this way.)

We've done two releases since then.  Putting the cookie at
the front of the structure makes us incompatible with *them*.
-1 on any changes at the front of STANDARD_MODULE_STUFF
for this reason.
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>