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/[email protected]/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/
-----------------------------------------------------------
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.
---------- 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
>
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
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".
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.
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