- Wine-Devel - list.winehq.org

Re: MSVCRT: Re-implement *printf
by Juan Lang Jan. 7, 2005

Jan. 7, 2005

Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 3

re: Announcing security hardened kernels for testing
by Mike Hearn Jan. 7, 2005

Jan. 7, 2005

Hi, Thanks for the great info. I'll CC this to wine-devel as I think it's of general interest, I hope you don't mind. For context, PaX is a set of security patches for Linux which lock down the system in a similar manner to exec-shield and SELinux. I say similar manner, because PaX seems to go further than these systems do - in fact from what I've read it seems to be the 'gold standard' in security patches. I'll quote the whole email and reply inline. This thread started on ubuntu-devel after one Ubuntu developer said they were experimenting with PaX, and I asked what the differences were between it and exec- shield (with which the community seems to have more experience) and why it was chosen. So I was pointed towards this thread: http://lists.debian.org/debian-devel/2003/11/msg00206.html in which the PaX author and Ingo Molnar who did exec-shield discuss the differences. On Wed, 2005-01-05 at 13:37 +0100, pageexec(a)freemail.hu wrote: > Hello, > > just ran across this thread on the ubuntu-devel list and have > a few observations: > > 1. PaX cares about backwards compatibility as much as it cares about > security, the best compromise we could make is that one can mark > executables to be exempt from PaX enforcements (and you should > have known about this as we'd talked about PaX+wine last year...). OK. I don't remember this thread I'm afraid but I do recall that you can exempt particular programs from PaX, so if a distribution wanted to integrate that it'd have to mark Wine as exempt by default. Presumably if WineHQ/CodeWeavers were to ship binary packages we'd have to do the same to work on such a distribution. But it's just an ELF flag right? > 2. as of the 20041201 snapshot of wine, it needs to be exempt from > at least ASLR [1], because it still makes some invalid assumptions > about the address space: > > - the highest mapping in the address space may not be the stack, > nor is the highest mapping (be that the stack or something > else) supposed to extend to the end of the userland address > space. the end result of this assumption is that some piece > of code in the preloader enters an infinite loop requesting > (but never getting) anon mappings above TASK_SIZE (0xc0000000 > typically). excerpt from an strace: > > mmap2(0xbffe0000, 262144, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ec0000 > munmap(0x77ec0000, 262144) = 0 > mmap2(0xbffe0000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xbffe0000 > mmap2(0xc0000000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ee0000 > munmap(0x77ee0000, 131072) = 0 > mmap2(0xc0000000, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ef0000 > munmap(0x77ef0000, 65536) = 0 > > the last lines then repeat indefinitely as the kernel would > never give out the request address, even with MAP_FIXED. We do this because some Windows programs and DLLs cannot cope with getting pointers >2gig, so we need to ensure that the kernel does not give us mappings above this point. The only way to do this currently is to do an iterative reservation to map as much of this address space as possible which is what you're seeing here. > - the above mentioned infinite loop also highlighted another bad > assumption wine makes: mmap() without MAP_FIXED but with a non-0 > hint is under no obligation to observe the hint and give you a > mapping at that address, under PaX it doesn't do so explicitly. > excerpt from an strace: > > mmap2(0x81000000, 1034813440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a420000 > munmap(0x3a420000, 1034813440) = 0 > mmap2(0x81000000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x81000000 > mmap2(0x9fd70000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x59190000 > munmap(0x59190000, 517406720) = 0 > mmap2(0x9fd70000, 258670592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x9fd70000 > > as you can see, wine insists on an address until it gets it, > without using MAP_FIXED. We have no choice in the matter, I think we can't use MAP_FIXED as that'd risk blowing away any mappings already made above the 2gig boundary. Actually this code was originally written to support the 4G/4G VM patch that was put into Fedora for a while (it's gone now). > 3. there's at least /usr/lib/wine/ntdll.dll.so which is marked with > an executable PT_GNU_STACK program header, suggesting that it > needs an executable stack (or there's some build problem). Last time I looked documentation on exactly what triggers this flag is scarce or non-existant. I remember asking Ingo if inline assembly still generated it and the answer back then was no, but I have no idea why gcc has decided it's needed now. If you look at ntdll in the sources: http://source.winehq.org/source/dlls/ntdll/ It's fairly harmless, there is some assembly in there but I don't remember seeing any code which assumed an executable stack. > this > alone would make wine fail under a PaX kernel as PT_GNU_STACK is > completely ignored there (because it's the wrong solution for the > wrong problem), nor is it allowed to generate code at runtime > (this applies to apps on which PaX is enforced of course, one can > always disable these on a per-executable basis). I'm afraid Wine cannot operate in an environment that doesn't allow us to map pages as executable and fill them with generated code. This technique is: a) Used by some Windows programs b) Used by the Wine DLL loader c) Required to implement DCOM universal interface proxies So if PaX denies this as a matter of course then it will never work. Having read the thread with Ingo I must say I agree with him that runtime code generation is a legitimate technique and not a bug. > i also have memories from about a year ago that kernel32.so had > some executable code snippets (some thunking code?) in .data or > some other otherwise non-executable area, that of course wouldn't > (and didn't) work under PaX either. back then Alexandre Julliard > suggested that this wasn't easy to rewrite (by also making the > now static code text reloc free) - has this been done since then? I don't think so, but I don't remember this thread either. > i also have strace excerpts that show how wine wanted to create > writable and executable memory, suggesting that it still wants to > generate code at runtime and this is how it fails under PaX (which > prevents runtime code generation by default): > > mmap2(NULL, 1179648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee0000 > munmap(0x7fff0000, 65536) = 0 > mprotect(0x7fee0000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) > munmap(0x7fee0000, 1114112) = 0 > write(2, "wine: failed to create the proce"..., 40wine: failed to create the process heap > ) = 40 > > on a sidenote, XP SP2 makes the default heap non-executable as > well, so if the above is the result of wanting to be compatible > with Windows, you may want to rethink it for the future. I'm not sure why it is, but yes I expect it's because some programs rely on it. Service Pack 2 may well make the default process heap NX but it also has a huge infrastructure in place to deal with backwards compatibility concerns, including a large database of badly behaved apps, user-accessible GUIs to disable the protections and I believe it also has code to catch NX faults (on hardware that supports that) and ask the user if they wish to disable the protections for that application. > 4. it would be nice if wine-preloader and wine-pthread had a configurable > base address, the current default makes them impossible to use > under the faster non-executable method of PaX/i386 (which halves > the userland address space, [2]). They have to be fixed otherwise the kernel may place them in the middle of a reserved area which would cause initialisation to fail. This cannot be changed. > so, right now wine can't run with a randomized address space, i have > yet to test if it can get away without generating code at runtime > and/or having writable/executable memory. It can't and I don't see any way to make it able to operate under such conditions in future. Is there a way to brand the binaries as excluded from PaX at build time without a special tool? If not would you be willing to submit a build system patch to detect the branding tool on PaX systems and use it on the relevant binaries automatically? thanks -mike

4 8

Re: winecfg fixes, now with actual patch
by Mike Hearn Jan. 7, 2005

Jan. 7, 2005

Crestez and I talked about this patch on #winehackers, and there are a few things that need to be changed (let's ignore the formatting changes here): - There was code to avoid a crash when the desktop value read from the registry doesn't have an x in it for some reason (yes this does happen) but this patch deletes it - mode_to_label is for translated, UI strings, not for stuff to be put in the registry. It does say this in a comment but I can appreciate that it looks at first glance like pointlessly duplicated code. We should fix this, especially as right now winecfgs translation support is weak. But for now the replacement of a case statement with a mode_to_label call is incorrect. thanks -mike On Fri, 07 Jan 2005 16:44:11 +0200, Crestez Leonard wrote: > This patch makes a bunch of small winecfg fixes. Since most of them are > just a few lines in length I don't think it's worth splitting them. > > Sorry for forgetting the attachment. > > Changelog: > winecfg: fix add application (memory error) > winecfg: fix apply button lighting up in audio tab > winecfg: fix video tab(crash when checking desktop, apply button not > lighting up > winecfg: fix apply button in libraries tab, fix memory leak in > parse_override, remove horrible abuse of macros in set_dllmode

1 0

Re: [winegcc] Include .so files when calling winebuild
by Dimitrie O. Paun Jan. 7, 2005

Jan. 7, 2005

On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote: > +void strarray_set(strarray* arr, int index, const char* str) > +{ > + if (index >= arr->maximum) > + { > + arr->maximum = index+10; > + arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum); > + memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size)); > + } > + arr->base[index] = str; > + if (arr->size <= index) > + arr->size = index+1; > +} Do we really need this strarray_set() function? Even if you do, it should _not_ shorten the array. -- Dimi.

2 3

tools/widl/write_msft.c warnings
by Gerald Pfeifer Jan. 7, 2005

Jan. 7, 2005

The addition of tools/widl/write_msft.c added the following four warnings, basically doubling the number of warnings we are getting with GCC 3.4. write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used write_msft.c:620: warning: `ctl2_alloc_importfile' defined but not used write_msft.c:918: warning: `ctl2_find_nth_reference' defined but not used write_msft.c:1382: warning: `set_help_file_name' defined but not used Would you mind looking into this? Gerald

1 0

Re: [AppDB] remove even more unused functions
by Tony Lambregts Jan. 6, 2005

Jan. 6, 2005

Jonathan Ernst wrote: > This patch removes unused functions from include/util.php > > Changelog: > - remove unused functions in include/util.php > > Files changed: > - include/util.php I believe you got carried away... two of those functions are used by make_bugzilla_version_list(): openbugzilladb() and closebugzilladb() values() is used in qclass.php which is used in stdquery.php which is used by query_appbyvendor.php, pn_buttons.php, appversion,php and a few others. If those files are not used then we should remove them first.

1 0

MSVCRT printf functions
by Aneurin Price Jan. 6, 2005

Jan. 6, 2005

I've gone over this patch again, fixed any bugs I could find, and tried to address the points made regarding readability. Hopefully the coding style should now be much improved, so could anyone who knows about such things give it a look over? If there's not too much of a problem there I'll fix up any points made and submit to wine-patches with the appropriate notes. I am still a little unsure about a couple of points; ones I can remember off the top of my head: probably insufficient attribution for code derived from file.c, since I have no idea who wrote the functions I used (these are specified in the copyright notice for printf.c, BTW). It's also pretty big; I presume it's okay to have this much in one file, but maybe not. Either way it can't be broken down into smaller patches since it's one big change. Thanks, Aneurin Price

2 1

Re: MSVCRT printf functions
by Juan Lang Jan. 6, 2005

Jan. 6, 2005

Hi Aneurin, some style comments on your patch: +<<<<<<< file.c +======= This shouldn't be in your patch. +typedef struct +{ + int flags; + unsigned int width; + __int64 precision; + const MSVCRT_wchar_t *input; + MSVCRT_wchar_t *output; + int HeapAlloced; + union + { + int intIn; + double doubleIn; + }; +} PRINTF_SPECIFIER; The HeapAlloced flag shouldn't be upper-cased. A BOOL may make more sense too. +PRINTF_SPECIFIER integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER specifier) This calling convention is a little strange. It's more typical in C not to return "large" things on the stack, but to use pointers instead. Since you use the specifier in the following way: + specifier = charprocessw(va_arg(*args, int),specifier); you may want to make the specifier an in/out parameter passed by pointer instead, e.g. void integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER *specifier) The calls would then look like: + charprocessw(va_arg(*args, int),&specifier); Finally, your internal functions should be made static. --Juan __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

RC file translation via winehq?
by Mike McCormack Jan. 6, 2005

Jan. 6, 2005

Hey All you web programmers out there! How hard to you think it would be to rig up a web page for people to do translations for wine on? Have a web page (translate.winehq.org?) into which we feed in all the .rc files and maybe even parts of WineHQ, and show the translations for each language and bits that are missing ... then accumulate all the bits of translation somehow so they can be sumbitted back to wine-patches. I think there's plenty of people who'd do translation work for us if they didn't have to bother learning about how to submit patches or understand how .rc files work. Mike

7 8

questions for safedisc implementation (AJ pleas read)
by Ivan Leo Puoti Jan. 6, 2005

Jan. 6, 2005

Chances are I'll be quite busy during the next week, but Laurent Pinchart, the guy who originally reverse engineered safedisc, asked a few questions on IRC about implementing support for the native safedisc driver, feedback, particularly from AJ, would be very appreciated, here is the IRC log. peter_pan is Laurent. < peter_pan> I'm trying to figure out how to implement "kernel services" in wine. a kernel service is a device driver which is loaded by StartService and runs in kernel space. the driver has a DriverEntry entry point, which, unlike regular services, seem to return immediately after registering callbacks. this might not always be the case though 23:41 < peter_pan> after DriverEntry returns, the process started by StartService currently exits. how should I handle calls to the callbacks registered by IoCreateDevice inside DriverEntry ? should they run in the calling process space, the wine server space or the service process space ? 23:41 < peter_pan> in the first case, I have to map the kernel service in all wine processes space, as the service can make use of global data (in windows the kernel service only exists once inside the kernel) 23:41 < peter_pan> in the third case, I will have to find a way to keep the service process alive (in a stopped state) after DriverEntry returns, and use wineserver and ptrace to call the callbacks from the user processes. this will imply inter process communication and inter process synchronization. or maybe I could just use IPC and keep the kernel space process waiting on a pipe or something. this wouldn't work for a kernel service which doesn't return from DriverEntry immediately, but I don't know if those exist. 23:41 < peter_pan> does anyone have any thought to share ? 23:47 <@Thunderbird> hi 23:47 <@Thunderbird> guess it needs to happen in wineserver 23:47 <@Thunderbird> better ask julliard about it 23:47 <@Thunderbird> if he is still awake 23:48 < peter_pan> he's been idling for 1 hour and 45 minutes 23:49 < peter_pan> are you there alexandre ? 23:50 <@Thunderbird> td might be online too .. 23:51 * TD is gone to a film, like NOW 23:51 <@TD> bye .... 23:51 < peter_pan> no luck either 23:51 < peter_pan> lol 23:52 <@Thunderbird> isn't there some function in wineserver that runs all the time? 23:53 < peter_pan> my opinion is that DriverEntry should be called in a separate process like it is now, as it can block, and that IoCreateDevice should map the image in the wineserver process space and update the callback table. the problem is that the changes to data sections made in DriverEntry must be somehow shared with wineserver. 23:55 < peter_pan> StartService will have to be modified to handle kernel services. it uses CreateProcess now, which calls DriverEntry (the entry point) with wrong parameters. we would need a way to mark a process as being a kernel process or a user process 23:57 <@Thunderbird> I guess that is good but I'm not qualified enough to say something about that 23:58 < peter_pan> using wineserver to host the driver callbacks would serialize the calls, which might not be a good thing to do. in windows, syscalls are executed in kernel space, but in the context of the calling process. it might be a good idea to do that here too. is the windows kernel interruptible ? can a process call a driver function while another process sleeps in the same functions, or while another process executes inside that function on another CPU ? 23:59 <@Thunderbird> how is this stuff handled in reactos? 23:59 < peter_pan> I have no idea 23:59 < peter_pan> maybe I should ask them

2 1