Ros-dev May 2006

ros-dev@reactos.org

41 participants
58 discussions

Missing validation in MmMapViewOfSection

by Myria

If the ImageBase for a given executable is in the kernel range (above 0x7FFE1000 or whatever), from reading the code it seems like no validation will stop it from going above that address. I have no way to try it out because I don't have reactos installed. Interestingly, in Windows XP SP2, the only illegal ImageBase values are: 7C800000 - Causes a dialog box to appear during the ntdll process initialization APC saying that the program can't run because kernel32.dll was relocated. 7C900000 - Causes PspMapSystemDll to fail. As a result, the process is never created and NtCreateProcessEx returns an error. These errors occur even when /fixed:no is used. Every other address is allowed by Windows as long as /fixed:no is specified, even above the user-kernel barrier. Personally I think reactos should allow user mode programs to shove ntdll and kernel32 out of the way, but that's just me =) Finally, 04477 MmUnlockAddressSpace(AddressSpace); 04478 return(STATUS_UNSUCCESSFUL); and the one below it should return STATUS_CONFLICTING_ADDRESSES, determined by attempting to load an image based at a kernel address without a relocation section. MmCreatePeb has an invalid assertion: ASSERT(Peb == (PVOID)0x7FFDF000); If the process's .exe already is at that address, the PEB will be at the wrong address. There's also a nice way for a user-mode program to bugcheck the kernel or leak a small amount of information in MmCreatePeb: ImageConfigData = RtlImageDirectoryEntryToData(Peb->ImageBaseAddress, To crash the kernel, put a bogus load config directory entry pointer in your .exe. To read an arbitrary dword or two, set up the load config pointer such that it aims at your desired memory address, then read the PEB's OSCSDVersion and ImageProcessAffinityMask values once your process starts. Melissa

18 years, 11 months

IsPowerOf2 is inefficient

by Myria

IsPowerOf2 in the kernel is badly inefficient. It should be this: __inline BOOLEAN IsPowerOf2(IN ULONG Number) { if (Number == 0) return FALSE; return (Number & (Number - 1)) == 0; } Not that this function is called frequently, shrug. Melissa

18 years, 11 months

Re: [Freedce-devel] pthread_clear_exit_np()

by Luke Kenneth Casson Leighton

okay, so these are the options: 1) forget redhat and forget them ever being helpful and supporting strategically important free software projects, and go back to using dcethreads posix draft 4 "emulation". 2) forget redhat and forget them ever being helpful and supporting strategically important free software projects, and put the cancellation "wrapper" side back into the dcethreads library - just keep the same posix "final draft" API. lord only knows what would happen on pthreads-win32 when compiling freedce with mingw32, with the "wrapper" stuff back in, but i'd be fascinated to find out. 3) think of ways to persuade the developers of glibc to enter into reasonable conversations and dialog to help support a strategically important free software project. how does any other project manage this (and what in hell's name prompted ulrich to be so dismissive?) On Fri, Apr 21, 2006 at 05:26:44PM +0200, thomas.schuetzkowski(a)web.de wrote: > Hi Luke, > > > > To make this work with libc we need to "un-cancel" a thread. > > ... > > Of course, using this in a third-party application is problematic as it > > depends on internal glibc structures. > > > > I know the chances of such an API being added to glibc are about nil, but > > I thought I'd mention this anyway! :-) > > We thought about adding a detection of the glibc version to autoconf stuff and choose the right version of the function. (see Loic's patch) > Then of course someone has to maintain this for every new version of glibc. :-( > > This idea was skipped, because no one had the time to do this. > > regards, > Thomas > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > -- -- lkcl.net - mad free software computer person, visionary and poet. --

18 years, 11 months

How does NTVDM allocate the zero page?

by Myria

How does NTVDM allocate memory at address 0 for the V86 IDT? Is it different in reactos vs. Windows? NtAllocateVirtualMemory won't allow that. Melissa

18 years, 11 months

Log off Crash

by James Tabor

Hi! Running at revision 21793, is this bug known to anyone? Doesn't happen often. Thanks, James (dll/ntdll/ldr/utils.c:1193) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2018) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2018) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (./subsystems/win32/win32k/objects/gdiobj.c:600) Attempted to free global gdi handle 0xe0500c1, caller needs to get ownership first!!! (./subsystems/win32/win32k/objects/gdiobj.c:600) Attempted to free global gdi handle 0x3e050301, caller needs to get ownership first!!! (lib/rtl/exception.c:75) RtlRaiseStatus(Status 0xc0000005) (./subsystems/win32/win32k/ntuser/message.c:1109) Failed to copy message to kernel: invalid usermode buffer (dll/win32/shell32/dialogs.c:420) LogoffWindowsDialog is UNIMPLEMENTED (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bedac (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bee9c (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bef94 (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bf08c (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bf914 (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1bfb0c (./subsystems/win32/win32k/ntuser/window.c:648) thread cleanup: while destroy wnds, wnd=0x9e1c00ec (./subsystems/win32/win32k/objects/gdiobj.c:805) Attempted to lock object 0x80063 that is deleted! KeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1241 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0xc0000005,0x80067d3a,0x00000000,0xfffffffc) *** ntoskrnl.exe - Address 0x80067d3a base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(2) Processor: 0 CS:EIP 8:80067d3a <ntoskrnl.exe:67d3a (ntoskrnl/ex/i386/fastinterlck_asm.S:580 (InterlockedDecrement))> cr2 fffffffc cr3 3cb2e000 Proc: 813df968 Pid: 70 <csrss.exe> Thrd: 817b0158 Tid: a4 DS 23 ES 23 FS 30 GS 0 EAX: ffffffff EBX: 00000001 ECX: fffffffc EDX: 00000001 EBP: 9ed9ebb4 ESI: 8d6d8328 ESP: 9ed9eb3c EDI: 00000003 EFLAGS: 00010297 kESP 9ed9eb3c kernel stack base 9ed99000 Frames: <win32k.sys:3dd22 (./subsystems/win32/win32k/eng/xlate.c:280 (IntEngCreateXlate))> <win32k.sys:71df3 (./subsystems/win32/win32k/objects/brush.c:64 (IntGdiCreateBrushXlate))> <win32k.sys:8bec8 (./subsystems/win32/win32k/objects/dc.c:2126 (NtGdiSelectObject))> <win32k.sys:8c1a1 (./subsystems/win32/win32k/objects/dc.c:2327 (DC_InitDC))> <win32k.sys:8ca37 (./subsystems/win32/win32k/objects/dc.c:923 (IntGdiCreateDC))> <win32k.sys:4ff56 (./subsystems/win32/win32k/ntuser/windc.c:121 (DceAllocDCE))> <win32k.sys:54678 (./subsystems/win32/win32k/ntuser/windc.c:441 (UserGetDCEx))> <win32k.sys:6498f (./subsystems/win32/win32k/ntuser/painting.c:770 (NtUserBeginPaint))> <ntoskrnl.exe:652b7 (ntoskrnl/ke/i386/trap.s:306 (KiFastCallEntry))> <win32csr.dll:5779 (subsystems/win32/csrss/win32csr/desktopbg.c:57 (DtbgWindowProc))>

18 years, 11 months

[ros-diffs] [janderwald] 21793: implement notepad view status bar - TODO: update caret position on arrow key/mouse scroll events

by James Tabor

Hi! --- trunk/reactos/base/applications/notepad/notepad.h (original) +++ trunk/reactos/base/applications/notepad/notepad.h Wed May 3 20:17:12 2006 @@ -5,7 +5,9 @@ #include <stdio.h> #include <windows.h> #include <commdlg.h> +#include <commctrl.h> #include <tchar.h> +#include <Richedit.h> #include "main.h" #include "dialog.h" [PCH] obj-i386/base/applications/notepad/notepad.h.gch base/applications/notepad/notepad.h:10:22: Richedit.h: No such file or directory make[1]: *** [obj-i386/base/applications/notepad/notepad.h.gch] Error 1 make[1]: Leaving directory `/home/ros/reactos' This patch breaks compile on a linux box! Please fix and remember!, This is a multi compiled platform operating system! So DoN't uSe CaSe! 8^D Thanks, James

18 years, 11 months

[lukeh@padl.com: NPTL and FreeDCE]

by Luke Kenneth Casson Leighton

guys, hi, am on the mailing list (subscribed) but am not receiving posts: please cc me if this would be an issue. for win32, i am using pthreads-win32: will reactos be able to support the trick that luke howard is referring to? l. ----- Forwarded message from Luke Howard <lukeh(a)padl.com> ----- Envelope-to: lkcl@localhost Delivery-date: Mon, 24 Apr 2006 12:51:50 +0100 X-Original-To: lkcl(a)lkcl.net Resent-Date: 24 Apr 2006 10:22:43 -0000 From: Luke Howard <lukeh(a)padl.com> Organization: PADL Software Pty Ltd To: freedce-devel(a)lists.sourceforge.net Subject: NPTL and FreeDCE Cc: opendce(a)opengroup.org Reply-To: lukeh(a)padl.com Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: NO, hits=-5.60 required=5.00 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Flag: NO X-Spam-Level: Resent-Message-ID: <UQB5HC.A.7PG.ubKTEB@mailman> Resent-To: opendce(a)opengroup.org Resent-From: opendce(a)opengroup.org X-Mailing-List: opendce:archive/latest/626 Resent-Sender: opendce-request(a)opengroup.org X-hands-com-MailScanner: Found to be clean X-MailScanner-From: opendce-request(a)opengroup.org Resent-Date: Mon, 24 Apr 2006 12:51:50 +0100 It may be possible to integrate DCE exception handling and NPTL so that longjmp() is never explicitly called from a cancellation cleanup handler. In fact, cleanup handlers need not be used at all. This approach requires the NPTL r ather than the LinuxThreads, API and is orthogonal to the previous issue about removing thread cancellation (that was a runtime issue present with NPTL regardless of which header one compiles against). Instead of calling _pthread_cleanup_push_defer(), we can store a __pthread_unwind_buf_t in the exception context and call __sigsetjmp() and __pthread_register_cancel_defer(). If __sigsetjmp() returns from a longjmp(), then we call dce_pthread_test_exit_np() to test whether the thread was cancelled, and set the current exception to pthread_cancel_e if necessary. No cleanup handler is necessary. The trick is that the code that raises an exception needs to call the internal API __pthread_unwind(), rather than longjmp(). Of course this ends up calling longjmp() anyway but hopefully does the right thing with respect to any other cleanup handlers that are registered. Another idea is to use the _Unwind_XXX API, but this strikes me as a little ambitious for now and I don't have any desire to interleave C++ and DCE exceptions. /* * For the NPTL API we share a setjmp/longjmp buffer between the * pthreads cancellation and DCE exception handling APIs. * * Note that we never actually call the cancellation function, we * just change the current exception context directly; this is the * same as calling dce_ptdexc_raise(&pthread_cancel_e) except that * __pthread_unwind() is not called. */ #define dce_exc_cleanup_push(cu, routine, arg) do \ { \ __exc_occured = __sigsetjmp((struct __jmp_buf_tag *)(cu)->__cancel_buf.__cancel_jmp_buf, 0); \ if (__exc_occured) \ { \ void *__status; \ \ if (dce_pthread_test_exit_np(&__status) == PTHREAD_STATUS_EXIT_NP \ && __status == PTHREAD_CANCELED) \ __exc_ctxt.exc = &pthread_cancel_e; \ } \ else \ { \ __pthread_register_cancel_defer(&(cu)->__cancel_buf); \ } \ } while (0) #define dce_exc_cleanup_pop(cu, execute) do \ { \ __pthread_unregister_cancel_restore(&(cu)->__cancel_buf); \ } while (0) /* make this a NOOP because we called it above */ #define dce_exc_setjmp(jmpbuf, val) /* we call __pthread_unwind() directly from dce_ptdexc_raise() */ #undef dce_exc_longjmp -- Luke -- ----- End forwarded message ----- -- -- lkcl.net - mad free software computer person, visionary and poet. --

18 years, 11 months

Re: [ros-bugs] [Bug 1185] OOo2 fails to install with an msi error.

by Magnus Olsen

This bug is on our side we can not test oo2 installer current in trunk. lest last time I try 1-2 Month back. for Reactos was to unstable to confrim if this bug still exists or not. It should not exits any longer. ----- Original Message ----- From: <ReactOS.Bugzilla(a)reactos.org> To: <ros-bugs(a)reactos.org> Sent: Tuesday, May 02, 2006 5:43 PM Subject: [ros-bugs] [Bug 1185] OOo2 fails to install with an msi error. > http://www.reactos.org/bugzilla/show_bug.cgi?id=1185 > > > > > > ------- Comment #7 from w3seek(a)reactos.com 2006-05-02 17:43 CET ------- > What's the status on this bug? Has the missing feature been implemented in > WINE? > > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs

18 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev May 2006