Ros-dev January 2006

ros-dev@reactos.org

69 participants
136 discussions

Another bug...
by Richard 17 Jan '06

17 Jan '06

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

1 0

uhhh...
by Richard 17 Jan '06

17 Jan '06

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

1 0

Strange Stretch Problem
by James Tabor 17 Jan '06

17 Jan '06

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

4 8

Bug in KiFastCallEntry
by Hartmut Birr 16 Jan '06

16 Jan '06

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

1 0

WMF Bug / SetAbortProc
by M Bealby 16 Jan '06

16 Jan '06

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

4 3

Re: [ros-diffs] [ion] 20911: - Fix some nasty context switch bugs:
by Hartmut Birr 16 Jan '06

16 Jan '06

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

1 0

Revision 20911 Boot Problems
by James Tabor 16 Jan '06

16 Jan '06

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

3 2

Listing function prototypes
by M Bealby 16 Jan '06

16 Jan '06

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

3 3

Re: [ros-svn] [weiden] 20891: disable starting lsass.exe for now
by Thomas Weidenmueller 15 Jan '06

15 Jan '06

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

2 1

Re: [ros-diffs] [ion] 20887: - Update KeContextToTrapFrame to support separate ContextFlags parameters in the scenario where we want to convert more then the Context's flag specify
by Thomas Weidenmueller 15 Jan '06

15 Jan '06

ion(a)svn.reactos.org wrote: > + Context->ContextFlags &= (~CONTEXT_EXTENDED_REGISTERS) | CONTEXT_i386; This looks a bit strange... - Thomas

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2006