Re: [1.7] rebaseall doesn't solve the problem
I've read the entire thread here http://cygwin.com/ml/cygwin/2009-02/msg00488.html and it seems to be the exact same problem I'm having. Discussion seems to have stopped though, I didn't seem any emails on it for the last three weeks or so. Is this fix or tool ready for end users, or testers? I've seen this rebase issue on Vista with both Perl and Python. Thanks, Jonathan [Below was written before reading the thread linked above] cygcheck output is attached minus the registry information, cygcheck seems to go into an endless loop on 64bit Vista when dumping registry information. I'm trying to run the django test server on a new created project with a trunk checkout of django. I have updated cygwin to the latest version and reinstalled python as well. % python manage.py runserver 90 [main] python 3852 C:\cygwin\bin\python.exe: *** fatal error - unable to remap C:\cygwin\bin\cygssl-0.9.8.dll to same address as parent(0x6B4A) != 0x6B4B 2 [main] python 5732 fork: child 3852 - died waiting for dll loading, errno 11 % python manage.py runserver 2 [main] python 6664 C:\cygwin\bin\python.exe: *** fatal error - unable to remap C:\cygwin\bin\cygssl-0.9.8.dll to same address as parent(0x6B4A) != 0x6B4B 3 [main] python 6748 fork: child 6664 - died waiting for dll loading, errno 11 Any help is much appreciated, Jonathan Cygwin Configuration Diagnostics Current System Time: Wed Apr 08 21:03:18 2009 Windows Vista Ultimate Ver 6.0 Build 6001 Service Pack 1 Running under WOW64 on AMD64 Path: C:\j2sdk1.4.2_06\bin .\ C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin .\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\X11R6\bin C:\cygwin\home\Jonathan\bin Output from c:\cygwin\bin\id.exe (nontsec) UID: 1000(Jonathan) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 10545(Users) Output from c:\cygwin\bin\id.exe (ntsec) UID: 1000(Jonathan) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 10545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows HOME = '/home/Jonathan' PWD = '/cygdrive/c/Users/Jonathan/Desktop' USER = 'jonathan' MAKE_MODE = 'unix' !:: = '::\' !C: = 'C:\' !ExitCode = '' ALLUSERSPROFILE = 'C:\ProgramData' APPDATA = 'C:\Users\Jonathan\AppData\Roaming' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' CommonProgramW6432 = 'C:\Program Files\Common Files' COMPUTERNAME = 'SAGER9262' COMSPEC = 'C:\Windows\system32\cmd.exe' configsetroot = 'C:\Windows\ConfigSetRoot' CYGWIN_ROOT = '\cygwin' DFSTRACINGON = 'FALSE' DISPLAY = '127.0.0.1:0.0' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Users\Jonathan' LOCALAPPDATA = 'C:\Users\Jonathan\AppData\Local' LOGONSERVER = '\\SAGER9262' NUMBER_OF_PROCESSORS = '4' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_ARCHITEW6432 = 'AMD64' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 23 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = '6' PROCESSOR_REVISION = '1707' ProgramData = 'C:\ProgramData' PROGRAMFILES = 'C:\Program Files (x86)' ProgramFiles(x86) = 'C:\Program Files (x86)' ProgramW6432 = 'C:\Program Files' PROMPT = '$P$G' PUBLIC = 'C:\Users\Public' RUN = '\cygwin\bin\run -p /usr/X11R6/bin' SESSIONNAME = 'Console' SYSTEMDRIVE = 'C:' SYSTEMROOT = 'C:\Windows' TERM = 'xterm' TRACE_FORMAT_SEARCH_PATH = '\\NTREL202.ntdev.corp.microsoft.com\34FB5F65-FFEB-4B61-BF0E-A6A76C450FAA\TraceFormat' USERDOMAIN = 'SAGER9262' USERNAME = 'jonathan' USERPROFILE = 'C:\Users\Jonathan' WINDIR = 'C:\Windows' XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults' XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt' XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB' XNLSPATH = '/usr/X11R6/lib/X11/locale' WINDOWID = '2097190' XTERM_VERSION = 'Cygwin 6.8.99.903(242)' XTERM_LOCALE = 'C' LOGNAME = 'jonathan' TERMCAP = 'xterm-r6|xterm|xterm X11R6 version:am:km:mi:ms:xn:co#145:it#8:li#53:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:' XTERM_SHELL = '/usr/bin/tcsh' HOSTTYPE = 'i386-cygwin' VENDOR = 'intel' OSTYPE = 'cygwin' MACHTYPE = 'i386' SHLVL = '1' GROUP = 'None' HOST = 'SAGER9262' REMOTEHOST = '127.0.0.1' MANPATH = ':/usr/ssl/man' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' SHELL =
Re: [1.7] rebaseall doesn't solve the problem
Jonathan wrote: I've read the entire thread here http://cygwin.com/ml/cygwin/2009-02/msg00488.html and it seems to be the exact same problem I'm having. Discussion seems to have stopped though, I didn't seem any emails on it for the last three weeks or so. Is this fix or tool ready for end users, or testers? I've seen this rebase issue on Vista with both Perl and Python. rebase-3.0-2 was announced here: http://cygwin.com/ml/cygwin/2009-04/msg00174.html and it includes the new peflags tool and peflagsall script. However... I've found that setting the ASLR flag on the DLLs *helps* on Vista -- but doesn't always work. Sometimes I'll still get the fatal error - unable to remap issue. This usually happens when: 1) The computer has recently hibernated 2) And I'm doing a TON of perl stuff with lots of fork/execs (e.g. autoreconf). It usually fixes itself if you reboot. This allows Vista to re-allocate the random base addresses, AND actually obey them. It's as if it forgets about ASLR after hibernation. -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Matthew Woehlke wrote:
Corinna Vinschen wrote:
On Feb 28 16:18, Charles Wilson wrote:
I'm open to suggestions. peimgflags? Currently, aslr only
peflags?
$0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
way it's a verb instead of a noun...
...except that the utility can also be used to display the flag values,
as well. So 'ch*' (as in 'change*') isn't very accurate, either.
--
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/
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote:
Matthew Woehlke wrote:
Corinna Vinschen wrote:
On Feb 28 16:18, Charles Wilson wrote:
I'm open to suggestions. peimgflags? Currently, aslr only
peflags?
$0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
way it's a verb instead of a noun...
except that the utility can also be used to display the flag values,
as well. So 'ch*' (as in 'change*') isn't very accurate, either.
Yes, I found that after I'd sent the above :-). Ah, well.
If the command is 'peflags --set-blah' (as is the case currently
IIUC), I think that's fine.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Still the prettiest. -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/
--
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/
Re: [1.7] rebaseall doesn't solve the problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:
Matthew Woehlke wrote:
Corinna Vinschen wrote:
On Feb 28 16:18, Charles Wilson wrote:
I'm open to suggestions. peimgflags? Currently, aslr only
peflags?
$0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
way it's a verb instead of a noun...
...except that the utility can also be used to display the flag values,
as well. So 'ch*' (as in 'change*') isn't very accurate, either.
--
Chuck
USD0.02 from another lurker: split it into two programs, lspeflags and
chpeflags (or whatever)?
- --
ABCD
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm2mFkACgkQOypDUo0oQOr5BgCdF/ylr0/+sM3jF7d9XpLnz4I3
wrMAoIkZBple24MfvzpVNA3MCwOgjO8D
=3pGf
-END PGP SIGNATURE-
--
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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote:
On Feb 28 16:18, Charles Wilson wrote:
I'm open to suggestions. peimgflags? Currently, aslr only
peflags?
$0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
way it's a verb instead of a noun...
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
You know what Microsoft's problem really is? They've lost the ability
to feel ashamed. -- Pamela Jones (Groklaw)
--
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/
Re: [1.7] rebaseall doesn't solve the problem
On Mar 4 01:01, Charles Wilson wrote: Charles Wilson wrote: Corinna Vinschen wrote: Can you tweak the tool so I can test that next week? Attached, It helps when you actually attach the file. Heh :) Thank you! I'll give it a whirl on my TS system. 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/
Re: [1.7] rebaseall doesn't solve the problem
On Mar 4 09:49, Corinna Vinschen wrote: On Mar 4 01:01, Charles Wilson wrote: Charles Wilson wrote: Corinna Vinschen wrote: Can you tweak the tool so I can test that next week? Attached, It helps when you actually attach the file. Heh :) Thank you! I'll give it a whirl on my TS system. Success! - I removed all Cygwin traces from my TS test machine. - I disabled DEP for all applications and rebooted (necessary so that the next step succeeds). - I installed a 1.7 distro from scratch. - I re-enabled DEP for all apps and rebooted. - I disabled the TS hack in the Cygwin DLL, rebuilt it and installed it on the TS machine. - I started bash and it crashed. - I started ash (always works for some reason). - I called ./peflags -t 1 /bin/bash - I started bash and... it worked! - I started GDB and it crashed. - I called ./peflags -t 1 /bin/gdb - I started GDB and it worked. - I started grep and... - I called ... /bin/grep - ... worked. - ... and ssh ... - ... and mkpasswd ... - ... and mkgroup ... So it seems that setting the TS-aware flag for all applications by default is the way to go, same as in Visual C++. Unfortunately that doesn't help us with existing packages in the distro, only for new ones, but at least we now have the peflags tool for these cases. Nevertheless, I will disable the TS hack in Cygwin 1.7 now. We have a much better solution now and the hack was a real PITA performance-wise. Thank you very much for doing that! I think this deserves a gold star. Igor? Are you still with us? I didn't see a mail from you since October. 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Success! - I removed all Cygwin traces from my TS test machine. - I disabled DEP for all applications and rebooted (necessary so that the next step succeeds). - I installed a 1.7 distro from scratch. - I re-enabled DEP for all apps and rebooted. - I disabled the TS hack in the Cygwin DLL, rebuilt it and installed it on the TS machine. - I started bash and it crashed. - I started ash (always works for some reason). - I called ./peflags -t 1 /bin/bash But it seems that the rebase package itself, when built, must be sure to mark peflags.exe as tsaware before packaging it for distribution, regardless of which ld.exe is used. Just in case -- otherwise the poor TS user won't be able to run peflags to fix everything else? That leads to a small chicken-and-egg problem if somebody tries to build the rebase package on a TS system, before the new ld is available. But we can live with that. - I started bash and... it worked! - I started GDB and it crashed. - I called ./peflags -t 1 /bin/gdb - I started GDB and it worked. - I started grep and... - I called ... /bin/grep - ... worked. - ... and ssh ... - ... and mkpasswd ... - ... and mkgroup ... Glad to hear it. So it seems that setting the TS-aware flag for all applications by default is the way to go, same as in Visual C++. Makes sense. Unfortunately that doesn't help us with existing packages in the distro, only for new ones, but at least we now have the peflags tool for these cases. Well, we will soon. There's still a few things to deal with. 1) code audit. I'd appreciate a thorough review of the code before recommending that people use this tool on every app in their installation. I know, no warranty express or implied, We're Just Mean, and You Get To Keep The Pieces, but still... 2) peflagsall 3) I'd like to make sure that the interface to peflags and the new option(s) to ld are the same or very similar. Once Dave posts his patch for ld to the binutils list, I'm sure there will be much bike-shedding about the name of the options, and perhaps discussion about the implementation. I'd like to wait for ld CVS to be updated with Dave's eventual contribution after those issues are resolved, and then make whatever changes to peflags seem appropriate before releasing the tool officially. 4) testing, testing, testing. Naturally. Until then, keep the URL to my previous message in this thread handy: Download peflags.c from ... and ... g Nevertheless, I will disable the TS hack in Cygwin 1.7 now. We have a much better solution now and the hack was a real PITA performance-wise. I guess, as long as that URL solution/FAQ answer is sufficient in the interim. Thank you very much for doing that! I think this deserves a gold star. Igor? Are you still with us? I didn't see a mail from you since October. I'm glad you're pleased with the tsaware facilities, but frankly I'm happier that the dynbase feature SEEMS to reduce the incidence of fork problems under Vista! My previously-working 1.7 installation became downright unusable last week before I wrote this tool. -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On Mar 4 09:59, Charles Wilson wrote: Corinna Vinschen wrote: [...] - I called ./peflags -t 1 /bin/bash But it seems that the rebase package itself, when built, must be sure to mark peflags.exe as tsaware before packaging it for distribution, regardless of which ld.exe is used. Just in case -- otherwise the poor TS user won't be able to run peflags to fix everything else? Well, my peflags.exe was not TS-aware and worked on TS. The bad joke is that some applications get broken by tsappcmp.dll and some not. I don't see any pattern. The below list (bash, ssh, grep, gdb, mkpasswd, mkgroup) is what I found to get screwed up, other stuff like ash, gawk, ls, nm, peflags, work fine. So it seems that setting the TS-aware flag for all applications by default is the way to go, same as in Visual C++. Makes sense. Unfortunately that doesn't help us with existing packages in the distro, only for new ones, but at least we now have the peflags tool for these cases. Well, we will soon. There's still a few things to deal with. 1) code audit. I'd appreciate a thorough review of the code before recommending that people use this tool on every app in their installation. I know, no warranty express or implied, We're Just Mean, and You Get To Keep The Pieces, but still... Well, I had a few tiny problems: - VERSION wasn't defined for some reason. - Just for kicks, try `peflags --show-image-characteristics=tsaware /bin/bash' (note: tsaware is a dll-characteristic, not an image-characteristic...) - Stuff like `./peflags.exe --show-dll-characteristics=tsaware' prints nothing at all. I guess it should print a help message due to a missing parameter instead. - peflags --help is missing linebreaks (line 1004 is missing a backslash 2) peflagsall 3) I'd like to make sure that the interface to peflags and the new option(s) to ld are the same or very similar. Once Dave posts his patch for ld to the binutils list, I'm sure there will be much bike-shedding about the name of the options, and perhaps discussion about the implementation. I'd like to wait for ld CVS to be updated with Dave's eventual contribution after those issues are resolved, and then make whatever changes to peflags seem appropriate before releasing the tool officially. Makes sense. Thanks, 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/
peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]
Corinna Vinschen wrote:
Well, I had a few tiny problems:
- VERSION wasn't defined for some reason.
Yeah, oops. That was -Ddefined by the makefile rule.
- Just for kicks, try `peflags --show-image-characteristics=tsaware /bin/bash'
(note: tsaware is a dll-characteristic, not an image-characteristic...)
My fault when de-binutils-ifying Dave's patch. einfo() never returns,
but I replaced it with fprintf(stderr,...). Fixed.
- Stuff like `./peflags.exe --show-dll-characteristics=tsaware' prints
nothing at all. I guess it should print a help message due to a missing
parameter instead.
Fixed.
- peflags --help is missing linebreaks (line 1004 is missing a backslash
Typo. '.' is right next to '\'.
Patch attached (and gzipped copy of fully-patched .c file). Still need
to compile using -DVERSION='2.4.5' or something:
gcc -o peflags.exe -DVERSION='2.4.5' peflags.c
Dave: none of Corinna's comments, nor my changes in addressing them,
point to any issues with your original patch for binutils.
--
Chuck
--- old/peflags.c 2009-03-04 01:00:38.89520 -0500
+++ new/peflags.c 2009-03-04 22:01:26.36120 -0500
@@ -184,10 +184,12 @@
int verbose = 0;
const char *file_list = 0;
const char *stdin_file_list = -;
+int mark_any = 0;
int
main (int argc, char *argv[])
{
+ int files_attempted = 0;
int i = 0;
parse_args (argc, argv);
@@ -198,35 +200,57 @@
int status = 0;
char filename[MAX_PATH + 2];
FILE *file = file_list_fopen (file_list);
+
if (!file)
exit (2);
while (file_list_fgets (filename, MAX_PATH + 2, file))
{
+ files_attempted++;
if ((status = do_mark (filename)) != 0)
break;
}
file_list_fclose (file);
+
+ if (files_attempted == 0)
+{
+ /* warn the user */
+ fprintf (stderr,
+ Error: Could not find any filenames in %s\n,
+ (strcmp(file_list, stdin_file_list) == 0 ? stdin : file_list));
+ exit (2);
+}
if (status != 0)
exit (2);
}
- /* Operate on files listed as command line arguments. */
+ /* Operate on files listed as command line arguments.
+ * Don't reset files_attempted because we do not require
+ * any args if -T filelist
+ */
for (i = args_index; i argc; i++)
{
const char *filename = argv[i];
+ files_attempted++;
if (do_mark (filename) != 0)
exit (2);
}
+ if (files_attempted == 0)
+{
+ /* warn the user */
+ fprintf (stderr, Error: no files to process\n);
+ short_usage (stderr);
+ exit (2);
+}
+
exit (0);
}
int
do_mark (const char *pathname)
{
- int mark_any = FALSE;
int has_relocs;
int is_executable;
int is_dll;
@@ -243,12 +267,6 @@
return 0;
}
- /* determine if we are actually to write anything. Skip
- entries in init[] that are display oriented */
- for (i = 0; init[i].ptr; i++)
-if (!strendswith (init[i].symbol, SHOWSTR))
- mark_any |= init[i].inited;
-
if (mark_any)
{
/* Skip if not writable. */
@@ -619,6 +637,13 @@
*(long *) init[c].ptr = val;
else abort ();
}
+
+ /* determine if we are actually to write anything. Skip
+ entries in init[] that are display oriented */
+ for (c = 0; init[c].ptr; c++)
+if (!strendswith (init[c].symbol, SHOWSTR))
+ mark_any |= init[c].inited;
+
}
int
@@ -901,8 +926,12 @@
if (flag)
flags |= flag-value;
else
-fprintf (stderr, Error: unrecognised integer/flag '%s' for PE parameter '%s'\n,
- optarg, name);
+{
+ fprintf (stderr, Error: unrecognised integer/flag '%s' for PE parameter '%s'\n,
+optarg, name);
+ short_usage (stderr);
+ exit (1);
+}
if (someVar-inited)
someVar-value |= flags;
@@ -966,15 +995,23 @@
long value;
value = strtoul (optarg, end, 0);
if (end == optarg)
-fprintf (stderr, Error: unrecognised integer/flag '%s' for PE parameter '%s'\n,
- optarg, name);
+{
+ fprintf (stderr, Error: unrecognised integer/flag '%s' for PE parameter '%s'\n,
+optarg, name);
+ short_usage (stderr);
+ exit (1);
+}
flags |= value;
optarg = end;
}
/* If there's any more, we do insist on at least one separator. */
if (*optarg !is_flag_sep (*optarg))
-fprintf (stderr, Error: unparseable at '%s' for PE parameter '%s'\n,
- optarg, name);
+{
+ fprintf (stderr, Error: unparseable at '%s' for PE parameter '%s'\n,
+optarg, name);
+ short_usage (stderr);
+ exit (1);
+}
}
set_pe_name (name, flags);
@@ -983,7 +1020,7 @@
static void
short_usage (FILE *f)
{
- fputs (Usage: peflags [OPTIONS] file...\n, f);
+ fputs (Usage: peflags [OPTIONS] file(s)...\n, f);
fputs (Sets or clears various flags in PE
Re: peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]
Charles Wilson wrote: Dave: none of Corinna's comments, nor my changes in addressing them, point to any issues with your original patch for binutils. Yep, so I see; I'm lurking. cheers, DaveK -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Dave Korn wrote: Nope, should be easy to cut out the relevant bits, discarding ld-isms, and paste the remainder into your code. Copy of WIP attached for your convenience; I've got to add doco and testcases before I can submit it, but the parsing stuff is ready to fly and I'd appreciate any extra testing it gets :) Two bugfixes FYI: static void set_pe_value_from_flags (char *name) after /* Deliberately allow multiple conjoined separators. */ while (is_flag_sep (*optarg)) optarg++; add /* Even trailing at the end. */ if (!*optarg) break; change /* If there's any more, we do insist on at least one separator. */ if (optarg !is_flag_sep (*optarg)) to /* If there's any more, we do insist on at least one separator. */ if (*optarg !is_flag_sep (*optarg)) cheers, DaveK -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Can you tweak the tool so I can test that next week? Attached, with Dave's symbolic flagname option parsing included. It's actually pretty standalone; you ought to be able to just do 'gcc -o peflags peflags.c' to build it. I'll work on the peflagsall script after the executable is a little more stable. The version has been tested moderately, but I wouldn't say thoroughly. -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote:
Corinna Vinschen wrote:
Can you tweak the tool so I can test that next week?
Attached,
It helps when you actually attach the file.
--
Chuck
/*
* Copyright (c) 2009 Charles Wilson
* Based on rebase.c by Jason Tishler
* Significant contributions by Dave Korn
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* A copy of the GNU General Public License can be found at
* http://www.gnu.org/
*/
#include stdio.h
#include time.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include string.h
#include unistd.h
#include getopt.h
#include errno.h
#include windows.h
typedef struct
{
const char *name;
int len;
int value;
} definfoflag;
#define C(name) { #name, sizeof(#name) - 1, name }
#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
static const definfoflag dllchrctnames[] =
{
/* Accept a few handy abbreviations. */
CF(dynbase, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
CF(forceinteg, IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
CF(nxcompat,IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
CF(noisolation, IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
CF(noseh, IMAGE_DLLCHARACTERISTICS_NO_SEH),
CF(nobind, IMAGE_DLLCHARACTERISTICS_NO_BIND),
CF(wdmdriver, IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
CF(tsaware, IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
/* And the full names as defined in the PE specification. */
C(IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
C(IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
C(IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
C(IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
C(IMAGE_DLLCHARACTERISTICS_NO_SEH),
C(IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
C(IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
{ 0, 0, 0 },
};
static const definfoflag imgfilechrctnames[] =
{
/* Accept a few handy abbreviations. */
CF(wstrim,IMAGE_FILE_AGGRESIVE_WS_TRIM),
CF(bigaddr, IMAGE_FILE_LARGE_ADDRESS_AWARE),
CF(sepdbg,IMAGE_FILE_DEBUG_STRIPPED), /* debug info in separate .dbg file
*/
/* And the full names as defined in the PE specification. */
C(IMAGE_FILE_RELOCS_STRIPPED),
C(IMAGE_FILE_EXECUTABLE_IMAGE),
C(IMAGE_FILE_LINE_NUMS_STRIPPED),
C(IMAGE_FILE_LOCAL_SYMS_STRIPPED),
C(IMAGE_FILE_AGGRESIVE_WS_TRIM),
C(IMAGE_FILE_LARGE_ADDRESS_AWARE),
C(IMAGE_FILE_BYTES_REVERSED_LO),
C(IMAGE_FILE_32BIT_MACHINE),
C(IMAGE_FILE_DEBUG_STRIPPED),
C(IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP),
C(IMAGE_FILE_NET_RUN_FROM_SWAP),
C(IMAGE_FILE_SYSTEM),
C(IMAGE_FILE_DLL),
C(IMAGE_FILE_UP_SYSTEM_ONLY),
C(IMAGE_FILE_BYTES_REVERSED_HI),
{ 0, 0, 0 },
};
typedef struct
{
void *ptr;
int size;
int value;
char *symbol;
int inited;
const definfoflag *flagnames;
} definfo;
#define D(var,symbol,def) {var,sizeof(var), def, symbol, 0, 0}
#define DF(var,symbol,def,flags) {var,sizeof(var), def, symbol, 0, flags}
#define DEFAULT_SHOW_DLL_CHARACTERISTICS
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE |\
IMAGE_DLL_CHARACTERISTICS_NX_COMPAT |\
IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE
#define DEFAULT_SHOW_IMG_CHARACTERISTICS0x0
static uint16_t ImgFileCharacteristicsSET;
static uint16_t ImgFileCharacteristicsCLR;
static uint16_t ImgFileCharacteristicsSHOW;
static uint16_t DllCharacteristicsSET;
static uint16_t DllCharacteristicsCLR;
static uint16_t DllCharacteristicsSHOW;
#define SHOWSTR show__
static definfo init[] =
{
DF(ImgFileCharacteristicsSET, __img_file_characteristics_set__, 0x0,
imgfilechrctnames),
DF(ImgFileCharacteristicsCLR, __img_file_characteristics_clr__, 0x0,
imgfilechrctnames),
DF(ImgFileCharacteristicsSHOW, __img_file_characteristics_ SHOWSTR,
DEFAULT_SHOW_IMG_CHARACTERISTICS, imgfilechrctnames),
DF(DllCharacteristicsSET, __dll_characteristics_set__, 0x0,
dllchrctnames),
DF(DllCharacteristicsCLR, __dll_characteristics_clr__, 0x0,
dllchrctnames),
DF(DllCharacteristicsSHOW, __dll_characteristics_ SHOWSTR,
DEFAULT_SHOW_DLL_CHARACTERISTICS, dllchrctnames),
{ NULL, 0, 0, NULL, 0, 0 }
};
#define OPTION_SET_IMAGE_FILE_CHARACTERISTICS150
#define OPTION_CLR_IMAGE_FILE_CHARACTERISTICS
OPTION_SET_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS
OPTION_CLR_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_SET_DLL_CHARACTERISTICS
OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_CLR_DLL_CHARACTERISTICS
OPTION_SET_DLL_CHARACTERISTICS+1
#define OPTION_SHOW_DLL_CHARACTERISTICS
OPTION_CLR_DLL_CHARACTERISTICS+1
#define OPTION_FLAG_HELP
OPTION_SHOW_DLL_CHARACTERISTICS+1
static struct option
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 21:28, Corinna Vinschen wrote: On Feb 28 14:51, Christopher Faylor wrote: On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), [...] Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Yes, that should be done in ld. I can add this now but I don't think it should be the default just yet. If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then I think the flag should be set by ld by default for Cygwin apps. Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option --peflags=[+-]tsaware|[+-]aslr|[+-]nx|[+-]wstrim (note that not all of these flags affect the same field in the pe header). or something even more generic but more powerful, WAY more dangerous, and harder to use, like --pehdrval=fieldname,hexval -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote: Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware ... etc ... cheers, DaveK -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Dave Korn wrote: Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware Nice. Where is the parsing done? I'm thinking of bringing in getopt_long support into rebase and peflags (which is available for both cygwin and mingw builds, just not MSVC. I don't think the rebase package cares about that). Anyway, if you've implemented that option parsing using just a small bit of magic over top of getopt_long, I'll just borrow it (both packages are GPL) and try to keep the interfaces for ld --pe-dll-characteristics peflags --dll-characteristics sorta similar (with maybe some nice short synonyms for the common peflags actions). OTOH, if it relies on a bunch of pre-existing ld/* glue, then... -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote:
Dave Korn wrote:
Yep, this is exactly how I'm doing it. Patch will be posted shortly.
Syntax looks like
--pe-dll-characteristics=name|integer[(+|,:)name|integer[...]]
e.g.
--pe-dll-characteristics=0x0400|0x0100
--pe-dll-characteristics=1+128+1024,noseh,nobind
--pe-dll-characteristics noseh:nobind:tsaware
Nice. Where is the parsing done?
I added a variant of pe.em#set_pe_name() that can understand those sorts of
arguments, and a field in the definfo struct that allows to supply a list of
the abbreviated names and their corresponding values, so the mechanism is
nicely reusable.
Anyway, if you've implemented that option parsing using just a small bit
of magic over top of getopt_long, I'll just borrow it (both packages are
GPL) and try to keep the interfaces for
ld --pe-dll-characteristics
peflags --dll-characteristics
sorta similar
Yep, that would obviously be A Good Thing (TM).
(with maybe some nice short synonyms for the common peflags actions).
The mechanism is ready and waiting for you, just add the data tables!
OTOH, if it relies on a bunch of pre-existing ld/* glue, then...
Nope, should be easy to cut out the relevant bits, discarding ld-isms, and
paste the remainder into your code. Copy of WIP attached for your
convenience; I've got to add doco and testcases before I can submit it, but
the parsing stuff is ready to fly and I'd appreciate any extra testing it gets
:)
cheers,
DaveK
? x.s
Index: include/coff/pe.h
===
RCS file: /cvs/src/src/include/coff/pe.h,v
retrieving revision 1.18
diff -p -u -r1.18 pe.h
--- include/coff/pe.h 4 Nov 2007 23:49:08 - 1.18
+++ include/coff/pe.h 3 Mar 2009 01:55:05 -
@@ -38,6 +38,17 @@
#define IMAGE_FILE_UP_SYSTEM_ONLY0x4000
#define IMAGE_FILE_BYTES_REVERSED_HI 0x8000
+/* DllCharacteristics flag bits. The inconsistent naming may seem
+ odd, but that is how they are defined in the PE specification. */
+#define IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE 0x0040
+#define IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY 0x0080
+#define IMAGE_DLL_CHARACTERISTICS_NX_COMPAT 0x0100
+#define IMAGE_DLLCHARACTERISTICS_NO_ISOLATION 0x0200
+#define IMAGE_DLLCHARACTERISTICS_NO_SEH 0x0400
+#define IMAGE_DLLCHARACTERISTICS_NO_BIND0x0800
+#define IMAGE_DLLCHARACTERISTICS_WDM_DRIVER 0x2000
+#define IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE 0x8000
+
/* Additional flags to be set for section headers to allow the NT loader to
read and write to the section data (to replace the addresses of data in
dlls for one thing); also to execute the section in .text's case. */
Index: ld/NEWS
===
RCS file: /cvs/src/src/ld/NEWS,v
retrieving revision 1.97
diff -p -u -r1.97 NEWS
--- ld/NEWS 18 Feb 2009 18:23:07 - 1.97
+++ ld/NEWS 3 Mar 2009 01:55:06 -
@@ -1,5 +1,9 @@
-*- text -*-
+* A new command-line flag '--pe-dll-characteristics' allows PE targets
+ to set the value of the PE file header's DllCharacteristics field,
+ using a flexible combination of numeric and symbolic names.
+
* PE targets no longer make use of the long section names PE extension to
the COFF format when generating executable images, by default. The old
(slightly non-conformant) behaviour can still be invoked by using the
Index: ld/emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.145
diff -p -u -r1.145 pe.em
--- ld/emultempl/pe.em 27 Feb 2009 19:01:56 - 1.145
+++ ld/emultempl/pe.em 3 Mar 2009 01:55:06 -
@@ -229,6 +229,8 @@ fragment EOF
(OPTION_USE_NUL_PREFIXED_IMPORT_TABLES
+ 1)
#define OPTION_DISABLE_LONG_SECTION_NAMES \
(OPTION_ENABLE_LONG_SECTION_NAMES + 1)
+#define OPTION_PE_DLL_CHARACTERISTICS \
+ (OPTION_DISABLE_LONG_SECTION_NAMES + 1)
static void
gld${EMULATION_NAME}_add_options
@@ -290,6 +292,7 @@ gld${EMULATION_NAME}_add_options
{large-address-aware, no_argument, NULL, OPTION_LARGE_ADDRESS_AWARE},
{enable-long-section-names, no_argument, NULL,
OPTION_ENABLE_LONG_SECTION_NAMES},
{disable-long-section-names, no_argument, NULL,
OPTION_DISABLE_LONG_SECTION_NAMES},
+{pe-dll-characteristics, required_argument, NULL,
OPTION_PE_DLL_CHARACTERISTICS},
{NULL, no_argument, NULL, 0}
};
@@ -303,14 +306,47 @@ gld${EMULATION_NAME}_add_options
typedef struct
{
+ const char *name;
+ int len;
+ int value;
+} definfoflag;
+
+#define C(name) { #name, sizeof(#name) - 1, name }
+#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
+static const definfoflag dllchrctnames[] =
+{
+ /*
Re: [1.7] rebaseall doesn't solve the problem
On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: Charles Wilson wrote: Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware I thought we'd established that these aren't just dll characteristics. cgf -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. cheers, DaveK -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. Yes, I am aware of this. Regardless, I don't think a publicly-exposed interface should be unclear like this. cgf -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. Yes, I am aware of this. Regardless, I don't think a publicly-exposed interface should be unclear like this. We can discuss this in depth on the binutils list when I submit the patch, there's not much point in having a long OT thread here. Let's see what the other PE stakeholders feel. cheers, DaveK -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 16:30, Charles Wilson wrote: Corinna Vinschen wrote: Only exes require the TS-aware bit. Two interesting snippets from MSDN: http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx But in order to set this flag without problems cropping up, you must satisfy: * The application does not run as a system service (that is, LUID=System). This probably isn't an issue for cygwin-1.7 and beyond, given the changes in how services are installed. (Dang, I need to release an updated csih...) I don't think you will get problems even if you're running a Cygwin application as system service. I don't know the exact reason for this rule, but all the TS-aware rules usually have something to do with don't change anything which might break the same application running in another user context. These rules don't have POSIX applications in mind. * The application does not write to the HKEY Local Machine registry hive for user specific data or configuration. Hmm. regtool? /proc/registry? Hmm, regedit? You're taking these rules too literally, imho. Either way, you lose. If we go one way, then you can't use regtool or /proc/registry to manipulate the virtualized registry entries, if you're trying to fix something related to a non-TS (windows) app. If we go the other way, then you can't use regtool or /proc/registry to manipulate the real non-virtualized registry. Cygwin applications won't use the virtualized registry keys anyway. 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/
Re: [1.7] rebaseall doesn't solve the problem
On Mar 1 10:47, Corinna Vinschen wrote: On Feb 28 16:30, Charles Wilson wrote: * The application does not write to the HKEY Local Machine registry hive for user specific data or configuration. Oh, btw., did you read the above closly? not write ... HKLM ... user specific. We don't do that. We don't use HKLM for user specific data or configuration. Only for system-wide data or configuration. Hmm. regtool? /proc/registry? Hmm, regedit? Which is to say, you can't use that rule on tools which are designed to manipulate the registry in general. 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/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 16:18, Charles Wilson wrote: 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 peflags? 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! Can you tweak the tool so I can test that next week? 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. +1 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. Something I forgot in my other reply from a few minutes ago: Cygwin applications are POSIX applications which are by default multiuser aware == TS-aware since they are written for such an environment. Should an application *prove* to make trouble in a TS-environment (minus the tsappcmp.dll bug) then we should try to find out why. In that case, especially if it's a plain POSIX tool, it might be a bug in Cygwin itself. Other than that, Cygwin and Cygwin apps are designed to interact cleanly in a multiuser environment. It should not matter under which account they are running, even SYSTEM. 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: I'm open to suggestions. peimgflags? Currently, aslr only peflags? Less typing is good. Can you tweak the tool so I can test that next week? Yes, I've finished my current round of package rebuilding; I'll try to get to peflags and peflags_all Monday PM. 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. +1 Ack. Cygwin applications are POSIX applications which are by default multiuser aware == TS-aware since they are written for such an environment. Should an application *prove* to make trouble in a TS-environment (minus the tsappcmp.dll bug) then we should try to find out why. In that case, especially if it's a plain POSIX tool, it might be a bug in Cygwin itself. Other than that, Cygwin and Cygwin apps are designed to interact cleanly in a multiuser environment. It should not matter under which account they are running, even SYSTEM. Ack. -- 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/
Hold off any new binutils release for one more upstream patch? [was Re: [1.7] rebaseall doesn't solve the problem]
Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? Well of course it's possible :) but looks like it would need a patch to ld. I'm going to be AFK most of this weekend, so please ping me Monday and I'll roll it up then. cheers, DaveK
Re: Hold off any new binutils release for one more upstream patch? [was Re: [1.7] rebaseall doesn't solve the problem]
On Feb 28 11:06, Dave Korn wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? Well of course it's possible :) but looks like it would need a patch to ld. I'm going to be AFK most of this weekend, so please ping me Monday and I'll roll it up then. No worris, I have to test that first, anyway :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [1.7] rebaseall doesn't solve the problem
On Feb 27 16:21, Charles Wilson wrote: Corinna Vinschen wrote: [...] I'm wondering if that's a result of ASLR in Vista. The document http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf [...] [...] If so, there's nothing Cygwin can do against that. In the long run, only a native fork() implementation would help. Well, maybe not! From the document you referenced: Since Windows relies on relocations instead of position independent code, a DLL must be loaded at the same address in each process that uses it to allow the physical memory used by the DLL to be shared. To facilitate this behaviour, a global bitmap called _MiImageBitMap is used to represent the address space from 0x5000 to 0x7800. The bitmap is 0x2800 bits in length with each bit representing 64KB of memory. As each DLL is loaded, its position is recorded by setting the appropriate bits in the bitmap to mark the memory where the DLL is being mapped. When the same DLL is loaded in another process, its section object is reused and it is mapped at the same virtual addresses. So, by marking a particular (or all but cygwin1.dll?) DLL as ASLR-compatibile, we may be able to coerce the Windows runtime loader into ensuring that the DLLs are loaded at the same memory location for all concurrent processes (unless the parent has filled up the space from 0x5000 to 0x7800, and so is forced to put an ASLR-compatible DLL somewhere else that is not tracked by _MiImageBitMap). I wrote a little utility to explicitly mark a DLL as ASLR-compatible. Using it on Cwd.dll -- the offending one in my situation -- I was able to eliminate the problem! Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? 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. 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. 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. Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? 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. -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On 2/28/09, Charles Wilson wrote: Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? +1 for that suggestion. It's doing something completely different. It will only work on systems with ASLR, which IIUC excludes XP SP1 and 2000. Even where it will work, rebasing might still be required if there are too many DLLs for _MiImageBitMap to track them all. Where it does work completely, the rebasing part of rebaseall should be unneeded, right? All of that seems to speak to a desire to have it available as a separate script, though maybe having a flag for rebaseall to call that script would be useful. Hope I didn't misunderstand any of this discussion... :-) ~Matt -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. 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. Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? I can add this now but I don't think it should be the default just yet. 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. Do the exes themselves need this bit as well as the dlls? cgf -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Well, I'm sure it would be useful there. However, just as ld can create a DLL with a user-specified image base, yet we still have a separate special purpose utility for rebasing them, it makes sense that ld can create an exe or dll with a specific pe_dll_characteristics flag, but a separate single-purpose utility to modify it is also useful. I really don't want Q. Random User to try and run objcopy confusing options on his entire installation... I can add this now but I don't think it should be the default just yet. Agree. BTW, this was mentioned on the binutils list about two years ago, but nothing ever came of it: http://sourceware.org/ml/binutils/2007-02/msg00046.html Do the exes themselves need this bit as well as the dlls? From what I understand, ASLR makes sense for both DLLs and EXEs -- but only if the image has relocations (most DLLs, and PIE exectuables). TS-Aware makes sense only for EXEs according to Corinna. NX could be applied to any DLL or EXE (I think). My mistake in the existing alsr code was to always skip if no relocations -- so since we don't have PIE exes, you can't currently set the TS or NX flags on ordinary exes with the tool. -- 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/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 13:47, Charles Wilson wrote: Corinna Vinschen wrote: Way cool, Chuck. Especially the fact that this tool can also mark executables with the TS-aware flag (doesn't make sense for DLLs, afaik). This helps to test if setting this flag in Cygwin binaries will allow Cygwin to run on 2008 with TS without disabling DEP. Well, the tool would need a little tweaking I think. Right now it skips any image (DLL or exe) that does not contain relocations. 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. If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), so we can get aslr integerated into rebase, and the rebaseall changes tested. Yes, sure. 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... 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. 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. 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/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 28 14:51, Christopher Faylor wrote: On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), [...] Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Yes, that should be done in ld. I can add this now but I don't think it should be the default just yet. If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then I think the flag should be set by ld by default for Cygwin apps. 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. Do the exes themselves need this bit as well as the dlls? Only exes require the TS-aware bit. Two interesting snippets from MSDN: http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx http://msdn.microsoft.com/en-us/library/01cfys9z.aspx The first one actually explains that the overhead of loading a compatibility DLL can be avoided by using the TS-aware flag. 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/
Re: [1.7] rebaseall doesn't solve the problem
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_AMD640x8664 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: Only exes require the TS-aware bit. Two interesting snippets from MSDN: http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx But in order to set this flag without problems cropping up, you must satisfy: * The application does not run as a system service (that is, LUID=System). This probably isn't an issue for cygwin-1.7 and beyond, given the changes in how services are installed. (Dang, I need to release an updated csih...) * The application does not write to the HKEY Local Machine registry hive for user specific data or configuration. Hmm. regtool? /proc/registry? Either way, you lose. If we go one way, then you can't use regtool or /proc/registry to manipulate the virtualized registry entries, if you're trying to fix something related to a non-TS (windows) app. If we go the other way, then you can't use regtool or /proc/registry to manipulate the real non-virtualized registry. Ditto for virtualized vs. non-virtualized /Program\ Files, /Windows, etc. THERE's the reason to keep an old cygwin-1.5 installation laying around! g http://msdn.microsoft.com/en-us/library/01cfys9z.aspx /TSAWARE is not valid for drivers, VxDs, or DLLs. Yep, need to fix aslr.exe to not do that. Also, I think I might use aslr to set the flag on my copy of NotePad++. I hate having to install the syntax colorizer plugins into both my and admin's virtualized Program Files directory...for every update... -- 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/
Re: [1.7] rebaseall doesn't solve the problem
Corinna Vinschen wrote: which means that locale.nls extends all the way down to 0x005E1000, so Cwd.dll can't go at 0x0086. Hm? Isn't that end_of_mapped_region = mapped_location + mapped_size? You're right. I was confused by the upside-down chart I was looking at. I'm wondering if that's a result of ASLR in Vista. The document http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf describes, starting at page 11, a registry key to influence Vista's ASLR behaviour. Does that change the behaviour for you? It *changes* the behavior, but doesn't fix it. the default case is key not present, or key present and equal to anything other than 0 or -1/0x. In this case, only those DLLs explicitly marked ASLR-compatible are supposed to be relocated -- subject to the other normal relocation rules. with the registry key set to 0 (disable ASLR, even if the DLL says it is ASLR-compatible), I get the same behavior as before: can't remap Cwd.dll. with the registry key set to -1/0x (force ASLR for all DLLs), I get slightly different behavior: can't allocate stack. Presumably this is because cygwin1.dll itself falls victim to relocation in this situation (verified this by looking at cygwin1.dll's load address). If so, there's nothing Cygwin can do against that. In the long run, only a native fork() implementation would help. Well, maybe not! From the document you referenced: Since Windows relies on relocations instead of position independent code, a DLL must be loaded at the same address in each process that uses it to allow the physical memory used by the DLL to be shared. To facilitate this behaviour, a global bitmap called _MiImageBitMap is used to represent the address space from 0x5000 to 0x7800. The bitmap is 0x2800 bits in length with each bit representing 64KB of memory. As each DLL is loaded, its position is recorded by setting the appropriate bits in the bitmap to mark the memory where the DLL is being mapped. When the same DLL is loaded in another process, its section object is reused and it is mapped at the same virtual addresses. So, by marking a particular (or all but cygwin1.dll?) DLL as ASLR-compatibile, we may be able to coerce the Windows runtime loader into ensuring that the DLLs are loaded at the same memory location for all concurrent processes (unless the parent has filled up the space from 0x5000 to 0x7800, and so is forced to put an ASLR-compatible DLL somewhere else that is not tracked by _MiImageBitMap). I wrote a little utility to explicitly mark a DLL as ASLR-compatible. Using it on Cwd.dll -- the offending one in my situation -- I was able to eliminate the problem! I've created it as a patch to the rebase package: 'aslr.exe' is a separate utility and doesn't actually use the imagebase library. I've also modified rebaseall to optionally call it after rebase. It seems to work okay; I've manually used it on a dozen or so DLLs -- but I'm still a little nervous about running it on EVERYTHING in my installation, since it doesn't quite have the history behind it that rebase does. Another pair of eyes (or dozen) looking at the code would be nice... Patch attached. Jason? -- Chuck diff -Nuar rebase-2.4.4-1-orig/Changes rebase-2.4.4-1/Changes --- rebase-2.4.4-1-orig/Changes 2005-07-28 09:29:49.0 -0400 +++ rebase-2.4.4-1/Changes 2009-02-27 16:13:32.156301300 -0500 @@ -1,5 +1,24 @@ $Id: Changes,v 1.3 2005/07/28 13:29:44 jt Exp $ +* New aslr utility allows to manipulate the following + flags in DLLs: + -a 1 -- Enable Address Space Layout Randomization + -a 0 -- Disable Address Space Layout Randomization + -n 1 -- Indicate that DLL is compatible with DEP (NX: no execute) + -n 0 -- Don't indicate compatibility with DEP + -t 1 -- Indicate that DLL is 'terminal-services aware' + -t 0 -- Don't indicate 'terminal-services' awareness + By default, cygwin DLLs have 0 for all three flags. Using + -n1/-t1 is untested, but -a1 may be useful on Windows Vista + and above. This is highly experimental; USE AT YOUR OWN RISK! + + Run the utility without any arguments to see the current + flag settings for a given DLL or list of DLLs. + +The following are the changes to rebaseall: +* Exclude cyglsa64.dll from rebase list +* Optionally run 'aslr -a 1' on each file after rebasing + 2.4: === The following are the changes to rebaseall: diff -Nuar rebase-2.4.4-1-orig/Makefile rebase-2.4.4-1/Makefile --- rebase-2.4.4-1-orig/Makefile 2008-06-07 16:40:49.0 -0400 +++ rebase-2.4.4-1/Makefile 2009-02-27 16:11:48.339101300 -0500 @@ -18,7 +18,7 @@ INSTALL = install CFLAGS = -O2 -I imagehelper -all: rebase +all: rebase aslr .PHONY: imagehelper @@ -30,12 +30,20 @@ -DLIB_VERSION='$(LibVersion)' \ -c -o $@ $ +aslr: aslr.o + $(CC) $(LDFLAGS) -o $@ aslr.o + +aslr.o: aslr.c Makefile + $(CC)
Re: [1.7] rebaseall doesn't solve the problem
On Feb 20 21:27, Charles Wilson wrote: Using process explorer, I find that for SOME reason, even in the parent perl, the Cwd.dll (one of the DLLs shipped with perl, in /usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in a strange location: Image Base: 0x5d6a Location in Parent: 0x0086 Location in Child : 0x014E I can't see that there is any conflict at the image base location of 0x5d6a, so I'm not sure why, in the parent, Cwd.dll was loaded that low. However, the low memory region is rife with conflict, and in fact, in the child: C:\Windows\system32\locale.nls image base: 0x0 mapped location: 0x0096 mapped size: 0x0037F000 which means that locale.nls extends all the way down to 0x005E1000, so Cwd.dll can't go at 0x0086. Hm? Isn't that end_of_mapped_region = mapped_location + mapped_size? Rebasing won't solve this problem, because Cwd.dll is NOT being loaded at the rebased (0x5d6a) location even tho, as far as I can tell, there is no conflict there. Instead, it's being loaded at a traffic heavy location for no good reason that I can see -- and I keep getting hit by passing cars. Help? I'm wondering if that's a result of ASLR in Vista. The document http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf describes, starting at page 11, a registry key to influence Vista's ASLR behaviour. Does that change the behaviour for you? If so, there's nothing Cygwin can do against that. In the long run, only a native fork() implementation would help. 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/
[1.7] rebaseall doesn't solve the problem
For the last several days I have been having a terrible time with the old 2 [main] perl 3620 C:\cygwin-1.7\bin\perl.exe: *** fatal error - unable to remap C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll to same address as parent(0x86) != 0x14E 5 [main] perl 3636 child_info::sync: wait failed, pid 3620, Win32 error 183 418 [main] perl 3636 fork: child 3620 - died waiting for dll loading, errno 11 issue. It's being triggered when running the autotools (so the libtool testsuite is a nightmare, as is trying to package anything using cygport for 1.7) -- and the culprit is ALWAYS Cwd.dll. I've tried rebasing to various addresses (0x7000, 0x6800, 0x650) but to no avail. Using process explorer, I find that for SOME reason, even in the parent perl, the Cwd.dll (one of the DLLs shipped with perl, in /usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in a strange location: Image Base: 0x5d6a Location in Parent: 0x0086 Location in Child : 0x014E I can't see that there is any conflict at the image base location of 0x5d6a, so I'm not sure why, in the parent, Cwd.dll was loaded that low. However, the low memory region is rife with conflict, and in fact, in the child: C:\Windows\system32\locale.nls image base: 0x0 mapped location: 0x0096 mapped size: 0x0037F000 which means that locale.nls extends all the way down to 0x005E1000, so Cwd.dll can't go at 0x0086. Rebasing won't solve this problem, because Cwd.dll is NOT being loaded at the rebased (0x5d6a) location even tho, as far as I can tell, there is no conflict there. Instead, it's being loaded at a traffic heavy location for no good reason that I can see -- and I keep getting hit by passing cars. Help? -- Chuck PS. The full output of sysinternal's listdll for the parent (first) and child (second) is below. But first: in the parent, there are three items that have an image base of 0x0, so they are relocated, in addition to Cwd.dll: name mapped to mapped size image base locale.nls 0x1999 0x0037f0000x0 locale.nls 0x00a1 0x0037f0000x0 oleaccrc.dll 0x008d 0x10000x0 Cwd.dll 0x0086 0x80000x5d6a In the (partially loaded) child, there is as yet only one copy of locale.nls loaded, and the Cwd.dll that are relocated from their actual image base: name mapped to mapped size image base locale.nls 0x0096 0x0037f0000x0 Cwd.dll 0x014e 0x80000x5d6a In each case, all of the other dlls are loaded at their actual image base and are not relocated. ListDLLs v2.25 - DLL lister for Win9x/NT Copyright (C) 1997-2004 Mark Russinovich Sysinternals - www.sysinternals.com -- perl.exe pid: 4948 Command line: C:\cygwin-1.7\bin\perl.exe -w /usr/bin/autom4te-2.63 --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh BaseSize Version Path 0x5206 0x8000C:\cygwin-1.7\bin\perl.exe 0x77a8 0x127000 6.00.6001.18000 C:\Windows\system32\ntdll.dll 0x763a 0xdb000 6.00.6001.18000 C:\Windows\system32\kernel32.dll 0x6100 0x30 1007.00.. C:\cygwin-1.7\bin\cygwin1.dll 0x76c1 0xc6000 6.00.6001.18000 C:\Windows\system32\ADVAPI32.DLL 0x76ab 0xc2000 6.00.6001.18051 C:\Windows\system32\RPCRT4.dll 0x5d76 0x184000 C:\cygwin-1.7\bin\cygperl5_10.dll 0x64ed 0x7000C:\cygwin-1.7\bin\cygcrypt-0.dll 0x7563 0x3b000 6.00.6001.18000 C:\Windows\system32\rsaenh.dll 0x77c1 0xaa000 7.00.6001.18000 C:\Windows\system32\msvcrt.dll 0x5d68 0xd000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Data\Dumper\Dumper.dll 0x5d05 0x9000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\IO\IO.dll 0x5d13 0x7000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Fcntl\Fcntl.dll 0x5cee 0x1c000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\POSIX\POSIX.dll 0x0086 0x8000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll 0x7613 0x2c000 6.00.6001.18000 C:\Windows\system32\apphelp.dll 0x73fd 0x32000 6.00.6001.18000 C:\Windows\system32\winmm.dll 0x7630 0x9d000 6.00.6001.18000 C:\Windows\system32\USER32.dll 0x7678 0x4b000 6.00.6001.18159 C:\Windows\system32\GDI32.dll 0x7648 0x144000 6.00.6001.18000 C:\Windows\system32\ole32.dll 0x767d 0x8d000 6.00.6001.18000 C:\Windows\system32\OLEAUT32.dll 0x7468 0x39000 4.02.5406. C:\Windows\system32\OLEACC.dll 0x7676 0x1e000 6.00.6001.18000 C:\Windows\system32\IMM32.DLL 0x76d1 0xc8000 6.00.6001.18000 C:\Windows\system32\MSCTF.dll 0x77cd 0x90006.00.6001.18000 C:\Windows\system32\LPK.DLL 0x768e 0x7d000 1.626.6001.18000 C:\Windows\system32\USP10.dll 0x6c1b 0x50008.00..0223
