February 2009 - Wine-devel - list.winehq.org

[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.14
by Paul TBBle Hampson 01 Feb '09

01 Feb '09

>From the discussion regarding the drawStridedSlow implementation of vertex blending, what shook out was the suggestion that WineD3D will need a vertex-program fixed function vertex pipeline at some point anyway, and therefore it doesn't make sense to add another software implementation to drawStridedSlow but to instead get the vertex pipeline in place and build the vertex blending functionality on top of that. Towards that aim, I've ported Stefan Dösinger's initial implementation of this from October last year [1] to what turned out to be 1.1.14. It fails two more D3D9 tests than 1.1.14: visual.c:914: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 visual.c:986: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 (I don't know if these failed when it was first implemented, so I don't know if the problem is the patch, the port, or even the test. This is on my nVidia 8600 w/180.22 binary drivers, in case it makes a difference.) I haven't run it with any games yet, or profiled it. Stefan's commented since that it was slower than the current system, albeit unoptimised, and that was the reason he didn't undertake any further work on it. I don't know what games use the fixed-function pipeline, so I'm open to suggestions and bug report references. All but the last patch in this tarball are ports of Stefan's original, and were done using git-am so still retain his original headers. The sorta-nasty no_d3dcolor_swizzle code in get_color and its caller in the last patch is entirely my fault though. ^_^ The last patch is actually also from Stefan's code, but it's an attempt by me to reinsert fog code I have removed, possibly incorrectly. However, it didn't fix the above fog failures, so I left it as a separate patch. I'm not totally sure I've got all the hard parts of the port right. The two relevant changes since these patches were applied were the implementation of EXT_vertex_buffer_bgra and the rearrangement of the fog code. For EXT_vertex_array_bgra and vertex_pipe->can_convert_d3dcolor, I'm not sure if there are places that check one and should check the other, and I'm not sure if the test in state.c line 4280 (streamsrc) is doing the right thing. I think it is doing the right thing. The vertex program recognises and handles a position_transformed vertex declaration itself. Of the original 13-patch series, patches 4 and 5 were rendered completely uninteresting by the fog changes, and 7 and 13 had already gone into the main tree. There was also what I believe was a bug in patch 2, which basically left pCaps->MaxUserClipPlanes uninitialised rather than fetching the value from the vertex_pipeline's get_caps method result. Anyway, here it is. I hope this is of benefit to someone. The next thing I plan to do with this is try and wrap my head around the internals of the arbvp vertex program so I can implement vertex blending there. [1] http://www.mail-archive.com/wine-devel(a)winehq.org/msg49501.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

2 1

[patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)
by Luke Kenneth Casson Leighton 01 Feb '09

01 Feb '09

http://bugs.winehq.org/attachment.cgi?id=19132 ok this is the beginnings of an implementation of messagemode, it passes the test1 and send2recv2 tests and fails the shortread test as part of PeekNamedPipe(). i'm not exactly sure why, yet. i get the distinct feeling that there's confusion over who writes into the wineserver data structures what the "availdata" is. msrpc.exe says "set availdata to 9", msrpcd.exe says "set it to 0, we did a write!" and it's all just ohhhh dear. also i have double-copies of server_set_named_pipe_info(), one in kernel32 and another in ntdll because i am using it in both places, i think SetNamedPipeHandleState() should be calling an NtFsControlIo rather than using server_set_named_pipe_info() but for the life of me i _really_ don't want to be finding out what the heck that function is :) hmm, maybe i can find out by copying ntdll.dll over to wine and doing a WINEDEBUG=trace+ntdll,kernel32 to see what functions get called. anyway the primary purpose of submitting the patch is to ask people if i'm along the right lines. anything seriously objectionable, etc. etc. l.

3 6

Fwd: A basic implementation for increased security in wine proposal
by Guillaume SH 01 Feb '09

01 Feb '09

---------- Forwarded message ---------- From: Guillaume SH <gsh.debianlists(a)gmail.com> Date: 2009/2/1 Subject: Re: A basic implementation for increased security in wine proposal To: Marcus Meissner <marcus(a)jet.franken.de> Hi Marcus, I stand corrected, as it appears I was way too naive in my understanding of software security, hence the example I provided. Regarding you explanation justifying there is no need to protect API against misuse, I am still not convinced, but I will think about it and try to get to a thorough understanding. Thank you for clarifying, Guillaume 2009/2/1 Marcus Meissner <marcus(a)jet.franken.de> > On Sun, Feb 01, 2009 at 10:41:25AM +0100, Guillaume SH wrote: > > > Hi Paul, > > > > You asked me to actually describe the security I am concerned about, so I > am > > going for it : > > > > Imagine an ill-intentioned people, call it the attackers. By the mean of > > simply creating the following C application (based on classical "Hello > > word") : > > > > > > #include needed header > > > > int main (int argc, char * argv[]) > > { > > /* printf ( "Hello world!" ); */ > > GetOverlappedResult(0, NULL, NULL, FALSE); > > > > return EXIT_SUCCESS; > > } > > > > > > Running this application on wine, I get to have my crash, with the > > possibility of an exploit. So all I have to do know is to find a vector > to > > make you and some other people willing to run my application. > > > > I won't describe in detail the way to perform the exploit as : > > 1 - I don't know how to proceed and I don't want to > > 2 - It would be showing poor sense of responsibilities > > If you can run an application ... it already can do everything! > > No need to protect APIs against misuse, they run at the same privilege > level as your code. > > Ciao, Marcus >

2 1

Re: [PATCH] kernel32: handle section=NULL in WritePrivateProfileStructW (Coverity)
by Nikolay Sivov 01 Feb '09

01 Feb '09

Marcus Meissner wrote: > Hi, > > CID 69, section name NULL will just crash in the calls below and > without it we cannot work anyway. So return FALSE; > > Ciao, Marcus > --- > dlls/kernel32/profile.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/kernel32/profile.c b/dlls/kernel32/profile.c > index 3c5ef1c..5dddc23 100644 > --- a/dlls/kernel32/profile.c > +++ b/dlls/kernel32/profile.c > @@ -1799,6 +1799,8 @@ BOOL WINAPI WritePrivateProfileStructW (LPCWSTR section, LPCWSTR key, > > if (!section && !key && !buf) /* flush the cache */ > return WritePrivateProfileStringW( NULL, NULL, NULL, filename ); > + if (!section) > + return FALSE; > > /* allocate string buffer for hex chars + checksum hex char + '\0' */ > outstring = HeapAlloc( GetProcessHeap(), 0, (bufsize*2 + 2 + 1) * sizeof(WCHAR) ); > What about a test on this? Does native module crash or not?

1 0

Re: [PATCH] winspool.drv: Check return value of EnumPrintersA
by Detlef Riekenberg 01 Feb '09

01 Feb '09

On Sa, 2009-01-31 at 11:09 +0100, Marcus Meissner wrote: > - EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 5, NULL, 0, &needed, > &num); > - if(needed) { > + if (EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 5, NULL, 0, &needed, > &num) && needed) { EnumPrinterA must always update "needed". "nedded" is 0, when EnumPrintersA failed or when no printer is installed. Line 1555 has similar code -- By by ... Detlef

2 1

A basic implementation for increased security in wine proposal
by Guillaume SH 01 Feb '09

01 Feb '09

Hi project, Following the two previous threads, I am posting here a draft patch implementing my proposal. So, to begin with I will remind you the principle : All function callable from outside wine, should be added sanity checks : if safe_mode_on and (sanity_check1_failed or sanity_check2_failed [...] ) { ExitWineCleanlyAndAdvertiseUser; } safe_mode_on value being read from registry (one and only time at wine startup). So if safe_mode_on is set to true, sanity check are performed and in case of failure wine advertise user and terminate cleanly Else, sanity check aren't performed and on a bad input wine is crashing. I've only produced a basic implementation, clearly marking as TODO items left to be done (by the way they are too much for me to handle, as I am no match for you when it comes to implementation). My goal here is firstly to demonstrate feasibility (hardly reached) and usefulness of the proposal. Secondly it is to provide something concrete. Please note than "unsafe" mode behave exactly the same than latest git version of wine (some more operations occur, however, so is not strictly equal in term of performance) I tested the two modes with the help of wine test suite, restricted to kernel/file.c, test_overlapped and I considered only : all must-be-successful tests GetOverlappedResult(0, NULL, &result, FALSE); GetOverlappedResult(0, &ov, NULL, FALSE); (these last two cannot be used in the same run, in either mode) Results are as follow (test are wine_test calls wine on linux(1) platform only ) : 1 - all must-be-successful tests 100% succeed in the two modes 2 - in safe mode, the last two triggers the user message and wine exit 3 - in unsafe mode, the last two triggers a crash Consequently, based on theses results no regression is identified. As I received some more informations in last thread (thank you for enhancing my comprehension of the problem), I will again expose the problem, taking them into account : The problem I am considering (and I may be mistaken here as I am not an expert) is called "Unchecked Error Condition"(2) and it is a referenced weakness (CWE id 391), rated "Medium" in likelihood of exploit, by serious people. Personally, I don't mind that Microsoft is ignoring it and promote usage of early crash or whatever. You are providing a software, presenting security defects that you choose not to fix because they are compliant with your goals. Consequently, at the very least you should explicitly advertise your users, confronting them with their responsibilities. I have read(3) on winehq a warning stating that wine is beta software, not ready for general use. I have read too about the "bug for bug" compatibility. So user's advertisement about security is rather thin and implicit. Please consider the problem, you need to do something about it, it is your responsibility. And continue the good work, you rocks ! Guillaume (1) wine version : wine 1.1.14 with the attached patch applied on top of it OS : debian testing amd64 (2) http://cwe.mitre.org/data/definitions/391.html (3) http://www.winehq.org/about/ PS : I have observed that you are very active about fixing other security issues : + buffer overflow + NULL pointer dereference + variable signedness + ... I seems to me that hopefully, you performs those fixes without consideration for "Is windows doing the same ?". I will be sad the day I will see a commit "Remove resource release because Windows is doing the same" or "Remove buffer overflow fix because app A (2 million copies sold) rely on it".

4 7

Re: dinput: Move gain support from effect to device
by Vitaliy Margolen 01 Feb '09

01 Feb '09

Vincent Pelletier wrote: > Hi. > > Windows supports setting force feedback effect gain at 2 levels: > - device > - effect > There is support for the former on Linux, but not for the latter. > > > + DWORD ff_gain; > }; ... > + This->ff_gain = max(0, (int) pd->dwData); First why do you typecase DWORD to (int) to assign to DWORD? Second DWORD will always be > 0. If you want to check it against limit then just check it being <= 10000 otherwise return error. > + if (This->joyfd != -1) { You should be checking This->base.acquired instead of fd. > + event.value = This->ff_gain * 0xFFFF / 10000; You should use MulDiv instead because this can be optimized out by compiler into something that won't be as accurate. Vitaliy.

2 1

Wine magazine articles?
by Dan Kegel 31 Jan '09

31 Jan '09

Hey everyone, does Wine have a gallery of press clippings anywhere? I couldn't find one, so I started one at http://wiki.winehq.org/Reviews just for long-form reviews. If you remember any good reviews of Wine (1.0 or later especially), please link them in there. - Dan

1 0