| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
SFU "DEP-problem" - what is it?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 SFU "DEP-problem" - what is it? - Mar. 16, '06, 5:50:18 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
There is a talk of the "DEP-problem" in SFU on this forum. What exactly is that?
I've read the article MSDN: Data Execution Prevention. Could it be the way memory is allocated by SFU?
If I'm right, an elegant solution would be to bypass the default memory allocation routines and allocate directly (ntdll.dll via psxdll.dll). Like this:
// heaptest.cpp - test of undocumented Interix heap functions
// Compile with Interix cc or Visual Studio
// link to libpsxdll.a, libc.a and crt0.o /nodefaultlib
#include <stdio.h> // for printf
#include <sys/utsname.h> // for uname
typedef void* HANDLE;
typedef unsigned long ULONG;
typedef unsigned long ULONG_PTR;
#define HEAP_GENERATE_EXCEPTIONS 0x00000004
#define HEAP_ZERO_MEMORY 0x00000008
#define HEAP_CREATE_ENABLE_EXECUTE 0x00040000
#define STATUS_NO_MEMORY 0xC0000017L
#define STATUS_ACCESS_VIOLATION 0xC0000005L
extern "C"
{
HANDLE __stdcall _GetProcessHeap(void);
HANDLE __stdcall _HeapCreate(ULONG dwFlags, size_t nInit, size_t nMax);
void* __stdcall _HeapAlloc(HANDLE hHeap, ULONG dwFlags, size_t nBytes);
void* __stdcall _HeapReAlloc(HANDLE hHeap, ULONG dwFlags, void* pMem, size_t nBytes);
long __stdcall _HeapFree(HANDLE hHeap, ULONG dwFlags, void* pMem);
void __stdcall _RtlRaiseException(ULONG dwCode, ULONG dwFlags, ULONG nArg, const ULONG_PTR* pArg);
};
__inline void* __cdecl my_malloc(size_t nBytes)
{
return _HeapAlloc(_GetProcessHeap(), 0, nBytes);
}
__inline void __cdecl my_free(void* pMem)
{
if(pMem) _HeapFree(_GetProcessHeap(), 0, pMem);
}
extern "C"
int __cdecl main()
{
utsname* pOSinfo = (utsname*)my_malloc(sizeof(utsname));
if(!pOSinfo) return -1;
int nRes = uname(pOSinfo);
if(nRes < 0) return -1;
const char pszFormat[] = "System = %s\nNode = %s\nRelease = %s\nVersion = %s\n";
printf(pszFormat, pOSinfo->sysname, pOSinfo->nodename, pOSinfo->release, pOSinfo->version);
my_free((void*)pOSinfo);
return 0;
}
Note: This is working in SUA, I have not been able test it in SFU
Comment:
The prototypes and defines are wild guesses taken from the kernel32 heap functions (see MSDN). These functions are more or less placeholders for the Rtl* functions in ntdll.dll. I therefore assume that this is likely also the case with the posix counterpart psxdll.dll - just guessing. Since we don't know what "_GetProcessHeap()" really do, we better use _HeapCreate with the HEAP_CREATE_ENABLE_EXECUTE flag. This only needed if the application is executing code in memory.
The /GS security cookie is a bit more tricky. A good starting point would be the excellent mini CRT implementation found in ATL's atlmincrt.
To see what's exported from psxdll.dll:
dumpbin.exe /linkermember libpsxdll.a > dump.txt or use the Dependency Walker tool - depends.exe
regards Jerker
|
|
|
|
|
RE: SFU "DEP-problem" - what is it? - Mar. 16, '06, 10:48:27 AM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Sorry, but you have not understood correctly and, in short, with the above wasted your time.
> Could it be the way memory is allocated by SFU?
No. It is the way that stack memory gets used by the gcc 3.3 compiler with SFU/Interix 3.5,
Specifically gcc creates executable code on the stack (MSVC never does). That's what DEP is about.
> If I'm right, an elegant solution would be to bypass the default memory allocation routines and allocate directly
Sorry, you are not right. And by the way, the Rtl* functions are what's used for memory allocation already.
> Note: This is working in SUA, I have not been able test it in SFU
The problem doesn't exist on SUA because the SUA gcc compiler has been patched to not place executable
code on the stack. Your code does nothing to control (and cannot) the stack.
> Since we don't know what "_GetProcessHeap()" really do, we better use _HeapCreate with the HEAP_CREATE_ENABLE_EXECUTE flag.
I've actually read all of the heap source code used for memory management.
But I'm not allowed to discuss it. One of those "I could tell you but I'd
have to shoot you after" things ;-)
You have the general intent here correct with the setting of the requested space as executable.
However, it is the stack that this needs to be done to at process creation time. By the time
your code starts it is already too late. The process is created by the system through a series
of special requests to build the process before it can run.
|
|
|
|
|
RE: SFU "DEP-problem" - what is it? - Mar. 16, '06, 11:55:50 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Well, even if I was wrong in general about the DEP-problem I had some fun ;-)
The code works and if I understand you right I got the prototypes in "general intent here correct" - good enough for me.
quote:
However, it is the stack that this needs to be done to at process creation time. By the time your code starts it is already too late. The process is created by the system through a series of special requests to build the process before it can run.
That means a new __PosixProcessStartup function?
I guess __PosixProcessStartup must look something like the mainCRTStartUp function found in the Win32 C runtime library. It would however be allmost impossible to write your own startup-code without exact knowledge of the original __PosixProcessStartup. So, speculating in this is fruitless. For other purposes than the DEP-problem it would however be a good thing. Overall, I think it's a drawback that we don't have access to the Interix LIBC. What's the big deal? Consider for example debugging, wide char console applications and when using parts of the MS C runtime.
quote:
No. It is the way that stack memory gets used by the gcc 3.3 compiler with SFU/Interix 3.5, Specifically gcc creates executable code on the stack (MSVC never does). That's what DEP is about.
So relating to another post - SFU binaries compiled by SUA gcc will not suffer of this?
|
|
|
|
|
RE: SFU "DEP-problem" - what is it? - Mar. 16, '06, 12:20:30 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> Well, even if I was wrong in general about the DEP-problem I had some fun ;-)
Good.
> That means a new __PosixProcessStartup function?
No.
You must understand that is this is an OS like MACH; it's not a monolithic kernel.
This function is called within the process. The process does not create itself.
The subsystem/kernel create the process and then start it running.
Each process communicates with it's subsystem with LPC's. This function, in part,
establishes/creates that communication. It does nothing with the stack. So
even if you change it nothing will change with DEP.
> Overall, I think it's a drawback that we don't have access to the Interix LIBC.
Libc has nothing to do with the startup.
If you want to know what most of the internals of libc look like then read any
of the BSD's libc sources.
> Consider for example debugging,
that's subsystem and kernel stuff
> wide char console applications
written the same way as on other Unix systems (wchar_t's etc.)
> and when using parts of the MS C runtime.
Nope. Not used at all. It sucked for stdio et al. That's why libc is used.
> So relating to another post - SFU binaries compiled by SUA gcc will not suffer of this?
Correct, provided that all libraries liked with are SUA built too.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
