This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]


On Jun  6 10:49, Corinna Vinschen wrote:
> On Jun  6 01:15, Dave Korn wrote:
> > Corinna Vinschen wrote:
> > 
> > > Not good.  I'm puzzled where this allocated 68K region is exactly coming
> > > from, but it really looks like something which occurs in or near dlopen.
> > > 
> > > I'm going to debug this further tomorrow.  I guess that goes without
> > > saying, but I'd be glad for any help.
> > 
> >   I'll just suggest that these problems can often be debugged more easily in
> > windbg than gdb, what with gflags/appverifier heap tracking, !vad, !heap, and
> > related commands.  The gflags FLG_HEAP_ENABLE_TAG_BY_DLL might come in handy here.
> 
> Right.  You might have noticed in my mail that I refer to WinDbg
> already.  It has a couple of invaluable helpers.  !vprot is one of my
> favorites, as well as the many available display formats in the memory
> window.
> 
> This morning I woke up and suddenly knew what's going on.  It's the size
> of a structure, which had a size of 320 bytes before.  Now it has a size
> of 65596 bytes since the filename stored in it is now a potentially 32K
> long wide character string.  The structure must be shrinked again.  I
> guess I have a patch by tonight.

Done.  The per-DLL structure is used to keep track of certain aspects of
each DLL linked at the executable or loaded at runtime.  In the latter
case, the post-fork procedure re-loads the DLL into the child.

The structure is allocated right after the space occupied by the DLL
itself, using VirtualAlloc.  I changed the struct layout so that the
size depends on the length of the pathname to the DLL.  In most, if not
all cases this will fit into a single 4K page.

The one problem with VirtualAlloc is the fact that it only allocates
memory on a 64K boundary.  So the DLL struct will be allocated exactly
in the next DLL slot in memory, wasting one place where a DLL can be
loaded.  However, in most cases the DLL itself will not occupy the
entire 64K slot, but one or more 4K pages are left free, which will
never be used while the application is running.

So I applied another patch this morning, which allocates a section
object (file mapping in Win32 speak) instead.  The NT kernel specifc
AT_ROUND_TO_PAGE flag allows to allocate section objects on 4K page
boundaries, rather than only on 64K allocation boundaries.  This allows
to allocate the DLL struct right after the DLL, in a memory slot which
will never collide with any further allocation or DLL.

The only downside is that the AT_ROUND_TO_PAGE flag is not supported by
WOW64, so the DLL struct will still be allocated on 64K boundaries on
64 bit Windows.

I tested this change on XP 32 bit, 2K8 32 bit, W7 32 bit, and W7 64 bit,
by running `cygport automake1.11 compile' and a subsequent `make check',
which uses perl (and thus run-time loaded DLLs) a lot.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]