I hereby resign from the position of Testing Coordinator. Casper,
could you please disable my svn account?
I am leaving for a variety of reasons. First of all, I wish to spend
more of my precious free time with my family. Second, work has become
more demanding of my time. There are many other reasons, including
the way major project issues are handled, and the fact I have not been
able to keep up with the testing and improvements I wished to
implement. This decision has been a long time coming.
It's been great getting to know the ReactOS developers and community,
and have learned a great deal from many of you. I will still stop in
IRC occasionally, and will continue to follow the project.
I think the Testing Coordinator position is a very important position,
and it needs to be filled. I feel that I was able to make a direct
impact on the quality of ReactOS, even though I am not a real
developer. I am willing to provide assistance and information to
anyone who wishes to step up to the position.
KEEP FILING BUGS!
Andrew Munger (WaxDragon)
Hi folks:
I was trying to update mi local mirror and fuond that the SVN server is no
longer the same. Wich is the new Address.
Thanks in advance
Regards
Waldo Alvarez
On 1/16/06, Richard <eek2121(a)comcast.net> wrote:
>
> I think it's time for me to hit up bugzilla, anyways, Firefox setup from
> mozilla.com no longer works, it just dies, and the 'get firefox' link
> results in an access denied in the middle of FF setup.
>
> Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be
> frozen, i can't tell.
>
> Regressions...Regressions...Regressions...
> Richard
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi,
many people mailed to me directly.
Sorry, If I didn't answered all of them.
Sorry if I only answer in the evening (EU). I've a day-job and my WAF
doesn't like ReactOS really.
- Hartmut
I think having to debug Alex's latest breakage (bugcheck at the end of 2nd
stage setup) so I can continue debugging one of his earlier breakages (bug
1263) is asking just a bit too much. I'll go do something non-ReactOS
related for the next couple of days.
GvG
I think it's time for me to hit up bugzilla, anyways, Firefox setup from
mozilla.com no longer works, it just dies, and the 'get firefox' link
results in an access denied in the middle of FF setup.
Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be
frozen, i can't tell.
Regressions...Regressions...Regressions...
Richard
When you click 'view GPL' for second stage setup, a license agreement
comes up for something called Gnomovision. This should not be the
case. I would change it myself but i don't have my svn password handy.
Richard
Hi all,
Can anyone see the problem with this picture? Every time I move the window,
it looks like back behind the window, it gets redrawn.
Thanks,
James
Hi,
it seems we have a little bug in KiFastCallEntry. It is initialized a
trap frame on the stack. It is a trap frame without the v86 segment
registers. ESP points to TSS->ESP0 - sizeof(KTRAP_FRAME) + 16. 16 for
the missing v86 segment register. ESP is compared with
KTHREAD->InitialStack - 0x29c. 0x29c is equal to sizeof(FX_SAVE_AREA) +
sizeof(KTRAP_FRAME). If the compare operation fails, it is called
BadStack which results in a v86 invalid opcode exception. To bypass this
bug, there is added a value of 0x10 to TSS->ESP0 in
Ke386InitThreadWithContext. A friend of me has looked to WinXp. He has
found a piece of code which is an exact copy of BadStack and he has
found a piece of code which looks like this:
_KiFastCallEntry:
...
/* Use the thread's stack */
mov ebp, [esi+KTHREAD_INITIAL_STACK]
...
/* Make space for us on the stack */
sub ebp, 0x29C
/* Write the previous mode */
mov byte ptr [esi+KTHREAD_PREVIOUS_MODE], UserMode
/* Sanity check */
cmp ebp, esp
jnz BadStack
...
- Hartmut
In case you've had you're head in the sand recently I'm sure you must
know about the recent WMF bug found in all recent versions of Windows.
The vulnerable function is in SetAbortProc and can be called from a
malicious WMF file as they include executable code by definition.
Windows automatically runs this a WMF file when previewing /
displaying - including from a web page!
WINE is also vulnerable, and still is. However, from a brief look at
my svn repo I think ReactOS is safe. SetAbortProc is in gdi32.dll,
and our version is well out of sync with WINE. I'm not sure if this
is intentional (I don't know which dll's we share directly), but
whoever implements this function must be very careful.
More info at:
http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx
They also have a patch there so anyone running Windows on their
machine is recommended to patch it immediately.
Cheers,
Martin
ion(a)svn.reactos.org wrote:
> - Fix some nasty context switch bugs:
> * We did not update the KPCR's stacklimit/initialstack with the new thread's stacklimit/initialstack.
> * We always assumed V86 frame bias in KeInitializeThreadContext.
> * We did not properly update ESP0 during context switch, to make space for the NPX frame and V86 bias.
> * We did not update fs:18h to point to the new TEB.
> * We did not clear out GS when switching processes, nor update the TSS's cr3.
> * If a new LDT was being updated, we over-wrote EBP (which was supposed to point to the TSS) by the GDT pointer.
> * We used a push/pop esp0 hack which hid the fact we never updated esp0.
> Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S
> Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S*
> @@ -114,10 +114,6 @@
>
> *--*/
> .globl @KiSwapContextInternal@0
> @KiSwapContextInternal@0:
>
> -#ifdef KDBG
> - //jmp SaveTrapFrameForKDB
> -SaveTrapFrameForKDB_Return:
> -#endif
>
>
> /* Get the PCR. It's faster to use ebx+offset then fs:offset */
> mov ebx, [fs:KPCR_SELF]
> @@ -132,24 +128,36 @@
>
> cli
>
> /* Save the initial stack in EAX */
>
> - mov eax, [edi+KTHREAD_INITIAL_STACK]
>
> + mov eax, [esi+KTHREAD_INITIAL_STACK]
>
Now eax points to the trap frame of the thread we will switch to.
>
>
> + /* Save the stack limit in ecx */
> + mov ecx, [esi+KTHREAD_STACK_LIMIT]
> +
> + /* Make space for the NPX Frame */
> + sub eax, NPX_FRAME_LENGTH
> +
> + /* Set the KPCR stack values */
> + mov [ebx+KPCR_INITIAL_STACK], eax
> + mov [ebx+KPCR_STACK_LIMIT], ecx
> +
>
> #ifdef CONFIG_SMP
> /* Save FPU state if the thread has used it. */
>
> + mov ecx, [edi+KTHREAD_INITIAL_STACK]
> + sub ecx, NPX_FRAME_LENGTH
>
> mov dword ptr [ebx+KPCR_NPX_THREAD], 0
> test byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_DIRTY
> jz 3f
> cmp dword ptr _KeI386FxsrPresent, 0
> je 1f
>
> - fxsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fxsave [ecx]
>
> jmp 2f
> 1:
>
> - fnsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fnsave [ecx]
>
> 2:
> mov byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_VALID
> 3:
> #endif /* CONFIG_SMP */
>
> -
>
> +
>
> /* Save the stack pointer in this processors TSS */
> mov ebp, [ebx+KPCR_TSS]
>
> @@ -158,12 +166,17 @@
>
> jnz NoAdjust
>
The compare operation uses eax which points to the thread we will switch
to. We must use the trap frame from the thread we will switch from.
> /* Bias esp */
>
> - //sub dword ptr ss:[ebp+KTSS_ESP0], KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
> + sub eax, KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
Eax points to the wrong stack. See above.
>
> NoAdjust:
>
> - /* Push ESP0 Value */
> - push ss:[ebp+KTSS_ESP0]
>
>
>
> + /* Set new ESP0 */
> + mov [ebp+KTSS_ESP0], eax
>
Now, we are using the wrong kernel stack on the next exception.
- Hartmut
