X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49A9AA0C.9020904@cwilson.fastmail.fm>
Date: Sat, 28 Feb 2009 16:18:04 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] rebaseall doesn't solve the problem
References: <499F6682 DOT 1090204 AT cwilson DOT fastmail DOT fm> <20090224100616 DOT GC6035 AT calimero DOT vinschen DOT de> <49A85971 DOT 6070300 AT cwilson DOT fastmail DOT fm> <20090228104337 DOT GG19887 AT calimero DOT vinschen DOT de> <49A986B4 DOT 2080501 AT cwilson DOT fastmail DOT fm> <20090228201625 DOT GA8503 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090228201625.GA8503@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Corinna Vinschen wrote:
> Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
> the tool should really be named differently.  Something suggesting
> that it in general changes Win32-related PE/COFF header flags.  ASLR
> and TS-aware are just some of them, in theory.

I'm open to suggestions.  "peimgflags"?  Currently, aslr only
manipulates the OPT_IMG_HEADER:DllCharacteristics field (which is a
misnomer, because some of the values apply to exe's).

We might also want to be able to set IMAGE_FILE_AGGRESIVE_WS_TRIM in the
IMAGE_FILE_HEADER:Characteristics field for things like sshd.



As currently coded, it *appears* that neither rebase nor aslr adapt to
the (slightly different) 64bit pe format.  Actually, I think only rebase
is affected by this, because the variations in the format occur past the
OPT_IMG_HEADER:DllCharacteristics offset.

I don't have a 64 bit machine to test on, so I'll have to pass on
"fixing" the imagehelper library used by rebase...

The differences are minor; larger field sizes for some values (and
therefore different field offsets for values past them). Just compare
and contrast IMAGE_OPTIONAL_HEADER32 and IMAGE_OPTIONAL_HEADER64 in
w32api/winnt.h.  From dlltool:

/*  & NumberOfRvaAndSizes.  */
#ifdef pe_use_x86_64
  num_entries = pe_get32 (dll, opthdr_ofs + 92 + 4 * 4);
#else
  num_entries = pe_get32 (dll, opthdr_ofs + 92);
#endif

#ifdef pe_use_x86_64
  export_rva  = pe_get32 (dll, opthdr_ofs + 96 + 4 * 4);
  export_size = pe_get32 (dll, opthdr_ofs + 100 + 4 * 4);
#else
  export_rva = pe_get32 (dll, opthdr_ofs + 96);
  export_size = pe_get32 (dll, opthdr_ofs + 100);
#endif

but I don't think #ifdefs are the way to go. We want to be able to
manipulate 64bit images on a 32bit machine, and vice versa -- based on
the value of the IMAGE_FILE_HEADER:Machine field.

IMAGE_FILE_MACHINE_I386		0x014c	x86
IMAGE_FILE_MACHINE_IA64		0x0200	Itanium
IMAGE_FILE_MACHINE_AMD64	0x8664	x64

Then again, maybe this isn't all that important, as the only 64-bit
image we have is cyglsa64.dll -- and my patch to rebaseall forces it to
skip that one anyway. Everything else in the cygwin distro is strictly
32 bits.

> I have to test if the TS-aware flag makes any difference on
> a 2K8 TS machine anyway.  I think (and hope) that this flag will
> persuade tsappcmp.dll into igoring an executable instead of scrambling
> its page executable protection flags.  If so, we should really set this
> flag in all applications.  Well, not that I gave up the idea that
> Microsoft should fix that bug in tsappcmp.dll in the first place...

Ha!

>> Should I also add a switch to rebaseall that means: ONLY alsr,
>> NO rebasing.  There's already a flag that allows you to add .exe's to
>> the "rebase" list -- but you can't remove dll's and .so's from the list.
> 
> Makes sense to me.

Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
 of code with rebaseall, but it's not really all THAT big a script.  The
reason I didn't do that originally was I wanted to reuse the same
(generated) filelist in each case.  But, it seems that the flexibility
in having aslrall(?) make its own file list -- which may include exe's
as well as dll's -- is more important.

>>> That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
>>> All newly built binaries would have the flag set already, and older
>>> binaries could be tweaked with the aslr utility.
>> That would be nice.  However, ONLY exe's linked with cygwin1.dll should
>> be marked this way, right?  Not cygcheck, strace, and whatever other few
>> exes we might find in the cygwin installation lists.
> 
> Hmm, I'm not sure about that one.  At least only EXEs should be marked
> TS-aware automatically.  The flag has no meaning on DLLs, afaik.
> *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
> help in all cases.  Cygwin applications are TS-aware by default anyway.
> If somebody actually manages to write a non-TS-aware Cygwin application,
> I'd say this guy should reset the TS-aware flag manually.

Oh, ok.

--
Chuck


--
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/