On Wed, Sep 18, 2013 at 12:38 PM, William A. Rowe Jr.
<[email protected]>wrote:

> On Thu, 12 Sep 2013 15:18:47 -0700
> Gregg Smith <[email protected]> wrote:
>
> > On 9/12/2013 11:10 AM, Jeff Trawick wrote:
> > >
> > > IIUC the Windows build is commit-then-review, so I'll commit the
> > > similar 2.4 changes to BaseAddr.ref based on a 64-bit debug build
> > > with Visual Studio 2012 tools.
> > >
> > No, the only thing in 2.4 I know of that is CTR is mod_lua, as for
> > anything else, if I thought it was CTR I'd have backported my
> > r1505178 at that time. That said however, I do not see this as
> > hurting as we have time to fix it if a problem is found before the
> > next tag. I'll run both release & debug builds myself this weekend
> > and look though the output. One never knows if there is a difference
> > between your cmake and my way of building the beast :)
>
> Please avoid re-sequencing modules during a subversion bump.  At least,
> apply the absolutely minimum delta (leave most modules where they are
> and move the offending module to a new, wider base address).
>

I'll try to add a different mode to fixBaseAddrs.pl that does that.

>
> This avoid potential load-time fixups if the user reverts to a prior
> or pushes to a newer module along the same major.minor release family.
> It's entirely reasonable (given our versioning rules) for someone to
> substitute a module prior to a regression being introduced, or for
> someone to replace only a single module to test whether or not the
> new module (/version) fixes a bug they are experiencing.
>
> On this topic, it's entirely reasonable that we might want to adopt
> (or let the builder elect to adopt) the load address randomization
> techniques, to make remote code execution harder to exploit.  Right
> now I think we have no (few) errors in run time symbol resolution
> (the reason which we do all the painful AP_DECLARE_DATA logic - this
> causes the data resolution to use indirection and subjects it to
> load time address fixups).  There are painful examples of where such
> logic can't work - openssl FIPS self-validation code, for example.
> But for the vast majority of httpd and apr distributed code, IJW.
>
>
>
>
Yep.


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Reply via email to