Mail Archives: cygwin/2009/02/28/16:20:02
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/
- Raw text -