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
Hi all,
WaxDragon gets this,
(lib/setupapi/devinst.c:3167) Flags 0x800000 ignored
(./lib/advapi32/service/scm.c:2035) dwBufSize: 0
(subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was cf)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xf000e739 could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65a69 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65d92 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a1f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cb1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00000c33>
kdb:>
I get this,
(lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv'
(Status c0000135)
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr
v' (Status c0000135)
(./subsys/win32k/ntuser/class.c:137) Failed to lookup class atom (ClassName 'SHE
LLDLL_DefView')!
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ec)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00003443>
<00000000>
kdb:>
Second reboot it worked after booting linux than reboot warm, third reboot by power on reset,
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ee)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00002eee>
<00000000>
kdb:>
I can repeat this over and over with real hardware,
Thanks,
James
Hey everyone, just a quick question.
Does anyone know of an existing application that will accept a bunch
of header files as input and output a list of function prototypes? It
would really help with my code auditing as I'm spending a long time
assembling them by hand and it takes a long while.
Cheers,
Martin
weiden(a)svn.reactos.org wrote:
> disable starting lsass.exe for now
It seems that rpcrt4.dll has a bug that massively leaks threads in an
rpc server. It seems that it leaks one thread per request.
- Thomas