X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Sat, 11 Sep 2010 12:30:10 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to 	thread-unsafe code in cwdstuff::set
Message-ID: <20100911103010.GM16534@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0AA AT MBX8 DOT EXCHPROD DOT USA DOT NET> <20100811084926 DOT GC26152 AT calimero DOT vinschen DOT de> <3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0B0 AT MBX8 DOT EXCHPROD DOT USA DOT NET> <AANLkTimpBCKzUioEarGiKMQbTjN+6s9iDYm_zzZ2Lxr9 AT mail DOT gmail DOT com> <20100812081151 DOT GT14202 AT calimero DOT vinschen DOT de> <3C031C390CBF1E4A8CE1F74DE7ECAF3A158EDA702A AT MBX8 DOT EXCHPROD DOT USA DOT NET> <20100903073740 DOT GA1749 AT calimero DOT vinschen DOT de> <3C031C390CBF1E4A8CE1F74DE7ECAF3A158EDA702D AT MBX8 DOT EXCHPROD DOT USA DOT NET> <20100904092626 DOT GE16534 AT calimero DOT vinschen DOT de> <3C031C390CBF1E4A8CE1F74DE7ECAF3A158EDA704C AT MBX8 DOT EXCHPROD DOT USA DOT NET>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3C031C390CBF1E4A8CE1F74DE7ECAF3A158EDA704C@MBX8.EXCHPROD.USA.NET>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Sep 11 00:12, John Carey wrote:
> On Sep 04 02:26 Corinna Vinschen wrote:
> > The problem only starts with Vista.  I have no objections to use
> > undocumented features, if they work.  If there's any way to replace the
> > cwd handle with our own *and* keep the Win32 API happy, I'll take it.
> 
> I think I've found a way to open the directory handle for backup intent
> on Vista and later versions.  Essentially, I emulate the new things that
> SetCurrentDirectory() is doing, but in order to get the necessary
> addresses, I have to do some very ugly hacks.
> 
> The proof-of-concept code follows (and is also attached).  It includes
> an analysis of what is going on--to the extent that I know what is going
> on, of course.  Please let me know what you think.

First of all, I'm thoroughly impressed.  This looks like a lot of
detective work and I'm also impressed by the amount of time you
apparently put into this.

I'm hopeful we can create something for Cygwin from this.  I have just
a few discussing points for now.

> The PEB does NOT seem to point to any VistaCwd instances.  Instead,

That puzzles me a bit...

> After creating the new VistaCwd instance; call it newCwd, the
> SetCurrentDirectory () implementation modifies the PEB and Cwd
> under a lock on CwdCS, as follows:
> 
>   Params.CurrentDirectoryHandle = newCwd.DirectoryHandle;
> 
>   Params.CurrentDirectoryName.Buffer = newCwd.Path.Buffer;

...because, at this point it *does* point to the newCWD, even if only
indirectly.  Let's name the VistaCwd structure Cwd points to "curCwd"
for now.  Since we have the address of curCwd.Path.Buffer in
Params.CurrentDirectoryName.Buffer, we can infer the address of curCwd
from here, right?  It's start is just a constant offset from the Buffer
address.

Given that, wouldn't it be potentially possible to override the content
of curCwd?  The problem is probably (just as in my old Cygwin code up to
1.7.5) to make sure that this is thread safe.  Probably we would still
need CwdCS.

>   cout << showbase << hex << (size_t)CwdCS
>        << "  <== critical section" << endl;
>   cout << showbase << hex << (size_t)Cwd
>        << "  <== Vista++ CWD struct pointer" << endl;

Is there any connection between these two addresses, like, say, they
are side by side?

Can't we find Cwd by scanning the .data segment of ntdll.h for the
address we inferred from the Params.CurrentDirectoryName.Buffer value?


Thanks,
Corinna

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

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