From: Henry N. <Henry.Ne@Arcor.de> - 2006-04-04 20:33:10
|
Hello, found an interesting problem. Perhaps this is the problem? In colinux source the file src/colinux/arch/i386/interrupt.c http://www.henrynestler.com/colinux/source/0.7.1-src/colinux_arch_i386_interrupt.c See the function "call_intr()". Is this an execution in stack frame? What does the "jmp *%0"? Objdump give that output for this line: ff 65 fc jmp *0xfffffffc(%ebp) Jump to address [ebp-4]. I think, it jumps to contains of [ebp-4] Is the destination address in an executable page? -- Henry Nestler |
From: Martin A. <ma...@af...> - 2006-04-04 22:07:26
|
Hello, I don't think so. I'm running coLinux with enabled DEP and am having no problems at all. The code you mention does nothing evil from my point of view. "%0" is just the first parameter that was passed to the function which should be (hopefully) a pointer to a function being in some executable page. It compiles to [ebp-4] because ebp (base pointer) is typically initialized at the beginning of a function to point between the arguments of the function (that were pushed to the stack) and the functions local variables so that [ebp-x] would give some argument and [ebp+x] would give some local variable (of course this depends on compiler settings and the used compiler itself). Regards, Martin Henry Nestler wrote: > Hello, > > found an interesting problem. Perhaps this is the problem? > > In colinux source the file src/colinux/arch/i386/interrupt.c > http://www.henrynestler.com/colinux/source/0.7.1-src/colinux_arch_i386_interrupt.c > > > See the function "call_intr()". > Is this an execution in stack frame? > > What does the "jmp *%0"? > Objdump give that output for this line: > ff 65 fc jmp *0xfffffffc(%ebp) > > Jump to address [ebp-4]. I think, it jumps to contains of [ebp-4] > Is the destination address in an executable page? > |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-04-07 07:59:28
|
Martin Afanasjew wrote: > I don't think so. I'm running coLinux with enabled DEP and am having no > problems at all. Have you a machine with hardware NXE (no execute)? And enought memory, so Windows enabled the PAE by default? > The code you mention does nothing evil from my point of view. "%0" is > just the first parameter that was passed to the function which should be > (hopefully) a pointer to a function being in some executable page. > > It compiles to [ebp-4] because ebp (base pointer) is typically > initialized at the beginning of a function to point between the > arguments of the function (that were pushed to the stack) and the > functions local variables so that [ebp-x] would give some argument and > [ebp+x] would give some local variable (of course this depends on > compiler settings and the used compiler itself). Ah. It's a simple "function pointer variable" for interrupt call fake. Thanks for comments. This GNU assembler is hard to read for me. I'm more a user of MASM. -- Henry Nestler |
From: Martin A. <ma...@af...> - 2006-04-07 13:50:23
|
Henry Nestler wrote: > Martin Afanasjew wrote: >> I don't think so. I'm running coLinux with enabled DEP and am having >> no problems at all. > > Have you a machine with hardware NXE (no execute)? And enought memory, > so Windows enabled the PAE by default? I have an Athlon 64 which has this feature and I checked if it is active according to [1]. It is and ProcessExplorer (from SysInternals) shows me that DEP is enabled for all colinux processes, too. According to some other KB article Windows enables PAE by default if you activate DEP regardless of the amount of memory that is installed (1 GB in my case). Regards, Martin [1] http://support.microsoft.com/kb/912923/ |
From: DrPizza <Dr...@qu...> - 2006-04-07 14:39:31
|
That is correct; the non-exec bit only exists when PAE-mode page tables are= used. Enabling DEP enables PAE. From: Martin Afanasjew Sent: Fri 07/04/2006 14:50 To: Henry Nestler Cc: col...@li... Subject: Re: [coLinux-devel] DEP/PAE boot.ini noexecute NX-bit Henry Nestler wrote: > Martin Afanasjew wrote: >> I don't think so. I'm running coLinux with enabled DEP and am having=20 >> no problems at all. >=20 > Have you a machine with hardware NXE (no execute)? And enought memory,=20 > so Windows enabled the PAE by default? I have an Athlon 64 which has this feature and I checked if it is active=20 according to [1]. It is and ProcessExplorer (from SysInternals) shows me=20 that DEP is enabled for all colinux processes, too. According to some other KB article Windows enables PAE by default if you=20 activate DEP regardless of the amount of memory that is installed (1 GB=20 in my case). Regards, Martin [1] http://support.microsoft.com/kb/912923/ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcas= t and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D1= 21642 _______________________________________________ coLinux-devel mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-devel |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-04-07 17:47:57
|
Hello, Martin Afanasjew wrote: > Henry Nestler wrote: >> Martin Afanasjew wrote: >>> I don't think so. I'm running coLinux with enabled DEP and am having >>> no problems at all. >> >> Have you a machine with hardware NXE (no execute)? And enought >> memory, so Windows enabled the PAE by default? > > I have an Athlon 64 which has this feature and I checked if it is active > according to [1]. It is and ProcessExplorer (from SysInternals) shows me > that DEP is enabled for all colinux processes, too. > > According to some other KB article Windows enables PAE by default if you > activate DEP regardless of the amount of memory that is installed (1 GB > in my case). Error was reported from Intel Pentium, not from AMD Athlon. Xeon 3.2GHz CPU with hyper-threading, 2GB RAM Is that only an Problem on Intel CPU? http://wiki.colinux.org/cgi-bin/NoExecuteDEP Please lets make an overview, where "/noexecute=AlwaysOff" in boot.ini solved the problem, and what CPU is running without change. Thanks. -- Henry Nestler |
From: <ra...@ab...> - 2006-04-07 21:17:39
|
Henry Nestler wrote: > > Is that only an Problem on Intel CPU? > > http://wiki.colinux.org/cgi-bin/NoExecuteDEP > > Please lets make an overview, where "/noexecute=AlwaysOff" in boot.ini > solved the problem, and what CPU is running without change. > Thanks. > Good idea. Everybody with unlisted CPU please fill in. For readability, I took the liberty to change the second AMD line to green since it worked with default boot.ini |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 07:37:26
|
Hello, Henry Nestler wrote: > Error was reported from Intel Pentium, not from AMD Athlon. > Xeon 3.2GHz CPU with hyper-threading, 2GB RAM > > Is that only an Problem on Intel CPU? > > http://wiki.colinux.org/cgi-bin/NoExecuteDEP is this hardware prefetching the condition for crashing on such Intel CPU? Anybody, please run a native linux with kernel >= 2.6.8 on Xeon CPU and check for the message "Errata 037". If this was printed, the coLinux switching code should also handle this special case? What is the "Errata 037"? Kernel Source linux-2.6.8/arch/i386/kernel/cpu/intel.c:117 Kernel Source linux-2.6.12/arch/i386/kernel/cpu/intel.c:64 /* * P4 Xeon errata 037 workaround. * Hardware prefetcher may cause stale data to be loaded into the cache. */ static void __devinit Intel_errata_workarounds(struct cpuinfo_x86 *c) { unsigned long lo, hi; if ((c->x86 == 15) && (c->x86_model == 1) && (c->x86_mask == 1)) { rdmsr (MSR_IA32_MISC_ENABLE, lo, hi); if ((lo & (1<<9)) == 0) { printk (KERN_INFO "CPU: C0 stepping P4 Xeon detected.\n"); printk (KERN_INFO "CPU: Disabling hardware prefetching (Errata 037)\n"); lo |= (1<<9); /* Disable hw prefetching */ wrmsr (MSR_IA32_MISC_ENABLE, lo, hi); } } } __ Henry |
From: Dave S. <ds...@uc...> - 2006-08-18 15:49:42
|
Henry Nestler wrote: >Hello, > >Henry Nestler wrote: > > >>Error was reported from Intel Pentium, not from AMD Athlon. >>Xeon 3.2GHz CPU with hyper-threading, 2GB RAM >> >>Is that only an Problem on Intel CPU? >> >>http://wiki.colinux.org/cgi-bin/NoExecuteDEP >> >> > >is this hardware prefetching the condition for crashing on such >Intel CPU? > >Anybody, please run a native linux with kernel >= 2.6.8 on Xeon CPU and >check for the message "Errata 037". If this was printed, the coLinux >switching code should also handle this special case? > >What is the "Errata 037"? > >Kernel Source linux-2.6.8/arch/i386/kernel/cpu/intel.c:117 >Kernel Source linux-2.6.12/arch/i386/kernel/cpu/intel.c:64 >/* > * P4 Xeon errata 037 workaround. > * Hardware prefetcher may cause stale data to be loaded into the cache. > */ > >static void __devinit Intel_errata_workarounds(struct cpuinfo_x86 *c) >{ > unsigned long lo, hi; > > if ((c->x86 == 15) && (c->x86_model == 1) && (c->x86_mask == 1)) { > rdmsr (MSR_IA32_MISC_ENABLE, lo, hi); > if ((lo & (1<<9)) == 0) { > printk (KERN_INFO "CPU: C0 stepping P4 Xeon detected.\n"); > printk (KERN_INFO "CPU: Disabling hardware prefetching (Errata >037)\n"); > lo |= (1<<9); /* Disable hw prefetching */ > wrmsr (MSR_IA32_MISC_ENABLE, lo, hi); > } > } >} > >__ >Henry > > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >coLinux-devel mailing list >coL...@li... >https://lists.sourceforge.net/lists/listinfo/colinux-devel > > Hi All, Could the problem be that the Intel processor is doing something different from the AMD processor WRT the NX bit? I have used the debug daemon and found that CoLinux crashes the system when it executes the psuedo context switch into the guest vm. I'm wondering if we just need to mark the passage page as executable in the page table of both the host and the guest. This would need to be done in the void *co_os_alloc_pages(unsigned long pages) function as the passage page isn't allocated with malloc(). There is a Windows API call -- VirtualProtect() -- that can change the NX bit on pages. I'm just having trouble getting the file to compile and link. The ./src/colinux/os/current/kernel/lowlevel/alloc.c file compiles ok but when CoMake tries to execute the following lines, the linker can't find __VirtualProtect@16. ----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<---- [src/colinux/os/winnt/kernel/lowlevel/alloc.o] Building: target is older than dependencies i686-pc-mingw32-gcc -Isrc -I/home/dschulz/build/linux-2.6.12-build/include -I/home/dschulz/build/linux-2.6.12-build/include2 -I/home/dschulz/build/linux-2.6.12-source/include -Wno-trigraphs -fno-strict-aliasing -Wall -mpush-args -mno-accumulate-outgoing-args -O2 -DCOLINUX -DCOLINUX_ARCH=winnt -DCOLINUX_DEBUG -DCOLINUX_FILE_ID=90 -DCO_HOST_API -DCO_HOST_KERNEL -DCO_KERNEL -DWINVER=0x0500 -D__KERNEL__ -c src/colinux/os/winnt/kernel/lowlevel/alloc.c -o src/colinux/os/winnt/kernel/lowlevel/alloc.o && i686-pc-mingw32-strip --strip-debug src/colinux/os/winnt/kernel/lowlevel/alloc.o src/colinux/os/winnt/kernel/lowlevel/alloc.c: In function `co_os_alloc_pages': src/colinux/os/winnt/kernel/lowlevel/alloc.c:35: warning: 'temp' might be used uninitialized in this function [src/colinux/os/winnt/kernel/lowlevel/build.o] Building: target is older than dependencies i686-pc-mingw32-ld -r src/colinux/os/winnt/kernel/lowlevel/time.o src/colinux/os/winnt/kernel/lowlevel/alloc.o src/colinux/os/winnt/kernel/lowlevel/wait.o src/colinux/os/winnt/kernel/lowlevel/timer.o src/colinux/os/winnt/kernel/lowlevel/debug.o src/colinux/os/winnt/kernel/lowlevel/misc.o src/colinux/os/winnt/kernel/lowlevel/user.o src/colinux/os/winnt/kernel/lowlevel/mutex.o -o src/colinux/os/winnt/kernel/lowlevel/build.o [src/colinux/os/winnt/kernel/build.o] Building: target is older than dependencies i686-pc-mingw32-ld -r src/colinux/os/winnt/kernel/fileio.o src/colinux/os/winnt/kernel/time.o src/colinux/os/winnt/kernel/alloc.o src/colinux/os/winnt/kernel/manager.o src/colinux/os/winnt/kernel/core.o src/colinux/os/winnt/kernel/block.o src/colinux/os/winnt/kernel/filesystem.o src/colinux/os/winnt/kernel/interface.o src/colinux/os/winnt/kernel/lowlevel/build.o -o src/colinux/os/winnt/kernel/build.o [src/colinux/os/winnt/build/driver.o] Building: target is older than dependencies i686-pc-mingw32-ld -r src/colinux/kernel/build.o src/colinux/os/winnt/kernel/build.o src/colinux/arch/build.o src/colinux/common/common.a -o src/colinux/os/winnt/build/driver.o [src/colinux/os/winnt/build/driver.base.exp] [src/colinux/os/winnt/build/driver.base.tmp] Building: target is older than dependencies i686-pc-mingw32-gcc -Wl,--base-file,src/colinux/os/winnt/build/driver.base.tmp -Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -o junk.tmp src/colinux/os/winnt/build/driver.o -lntoskrnl -lhal -lgcc ; rm -f junk.tmp src/colinux/os/winnt/build/driver.o: undefined reference to `_VirtualProtect@16' collect2: ld returned 1 exit status [src/colinux/os/winnt/build/driver.base.exp] Building: target is older than dependencies i686-pc-mingw32-dlltool --dllname linux.sys --base-file src/colinux/os/winnt/build/driver.base.tmp --output-exp src/colinux/os/winnt/build/driver.base.exp [src/colinux/os/winnt/build/linux.sys] Building: target requires creation i686-pc-mingw32-gcc -Wl,--subsystem,native -Wl,--image-base,0x10000 -Wl,--file-alignment,0x1000 -Wl,--section-alignment,0x1000 -Wl,--entry,_DriverEntry@8 -Wl,src/colinux/os/winnt/build/driver.base.exp -mdll -nostartfiles -nostdlib -o src/colinux/os/winnt/build/linux.sys src/colinux/os/winnt/build/driver.o -lntoskrnl -lhal -lgcc src/colinux/os/winnt/build/driver.o: undefined reference to `_VirtualProtect@16' collect2: ld returned 1 exit status Error: Target not build (TargetNotBuildError) make[1]: *** [colinux] Error 1 ----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<---- The sourcecode: NOTE:I've tried about a hundred different variations of the includes, this is just one of them. ----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<---- #include <asm/page.h> #include <colinux/os/alloc.h> #include <colinux/os/kernel/alloc.h> #include <windows.h> #include <winbase.h> #include "../ddk.h" #ifdef DEBUG_CO_OS_ALLOC static int allocs; #endif void *co_os_alloc_pages(unsigned long pages) { void *ret; PDWORD temp; if (pages == 0) KeBugCheck(0x11117777); ret = MmAllocateNonCachedMemory(pages * PAGE_SIZE); VirtualProtect((LPVOID)ret, pages * PAGE_SIZE, 0x40, temp); #ifdef DEBUG_CO_OS_ALLOC if (ret) { allocs++; co_debug("%s:%d(%d)->%x\n", __FUNCTION__, allocs, pages, ret); } #endif return ret; } ----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<---- I hope this helps. I know it isn't the stuff of an assembly guru :) OH, I should probably mention that the processor is a P4 630 with HyperThreading and 1Gig of RAM. causing the IRQL_NOT_LESS_OR_EQUAL BSOD. -Dave -- =============================== Dave Schulz High Performance Computing University of Calgary ds...@uc... |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 16:17:09
|
Hello Dave, Dave Schulz wrote: > [...] > when CoMake tries to execute the following lines, the linker can't find > __VirtualProtect@16. You need to add the library libkernel32.a, for sample as -lkernel32 But, is VirtualProtect a Windosw Kernel funktion (from DDK, not SDK)? The passage page must be executable on both sides. The execute flag for the passage page should be schanged by the wrapper function nx_protect_switch_wrapper() in antinx.c, than the normal switcher runs with co_switch(). This is a short comment only. I will check (and understanding) your ideas later. > I hope this helps. I know it isn't the stuff of an assembly guru :) > > OH, I should probably mention that the processor is a P4 630 with > HyperThreading and 1Gig of RAM. causing the IRQL_NOT_LESS_OR_EQUAL BSOD. Yes the P4 630 is a typical candidate. The three caps lines and the workarrounts ("Enabling ...") on this cpu from kernel boot are interesting from native linux boot. With this we can locate what specific code will be run oon standard linux. dmesg | grep "CPU: " CPU: After generic identify, caps: 3febf9ff 00000000 00000000 ... CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 ... CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 ... CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz stepping 04 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. -- Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 16:25:52
|
Henry Nestler schrieb: > Hello Dave, > > Dave Schulz wrote: >> [...] >> when CoMake tries to execute the following lines, the linker can't find >> __VirtualProtect@16. > > You need to add the library libkernel32.a, for sample as -lkernel32 > But, is VirtualProtect a Windosw Kernel funktion (from DDK, not SDK)? Sorry, VirtualProtect is a SDK function. You can not call from kernel driver linux.sys: http://msdn.microsoft.com/library/en-us/memory/base/virtualprotect.asp -- Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 18:05:35
|
Hello, this is the shortest official doc about Xeon and NX bit, directly from Intel. Please download the PDF from "page 2": http://www3.intel.com/cd/ids/developer/asmo-na/eng/149308.htm Found on this page: http://support.intel.com/design/xeon/documentation.htm -- Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 19:33:22
|
Hello, http://article.gmane.org/gmane.linux.colinux.general/3021 from Jon have report about CPU Processor Name: Intel(R) Xeon(TM) CPU 3.20GHz Type: 0 Family: F Model: 4 Stepping: 3 Revision: 5 L1 Trace Cache: 12 K=B5ops L1 Data Cache: 16 KB L2 Cache: 2 MB L3 Cache: None Packaging: 604 pin =B5PGA EIST: No MMX(TM): Yes SIMD: Yes SIMD2: Yes SIMD3: Yes Enhanced Halt State: Yes Execute Disable Bit: Yes Hyper-Threading Technology: Yes Intel(R) Extended Memory 64 Technology: Yes Intel(R) Virtualization Technology: No Reported Processor Frequency: 3.20 GHz Reported System Bus Frequency: 800 MHz For this, found errata by intel: http://support.intel.com/design/xeon/specupdt/302402.htm From this paper 30240222.pdf, we should check all bugs about this CPU=20 in IA32 mode. --=20 Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-18 16:49:24
|
Hello, found an interesting overview about difference IA-32e and AMD64 http://marc.theaimsgroup.com/?l=linux-kernel&m=107766481408468&w=2 The intersting is: "Syscall/sysret is supported only in 64-bit mode (not in compatibility mode)." What says that? Syscall/sysret exist on old 32 bit CPU, but not on 64 bit Intel in emulated 32 bit mode? Would it help to disable some of the features for the Xeon CPU? Some of featues can disable by kernel boot parameters, for sample "nosep" (2.6.17 only), "nofxsr", "nomce", "mce" Please grep for "__setup" in linux-2.6.17/arch/i386/, to see what new kernels have as options. This or more options we could add to coLinux to find the workarrount? -- Henry Nestler |
From: Nuno L. <nt...@gm...> - 2006-04-06 23:57:22
|
On 4/4/06, Henry Nestler <Hen...@ar...> wrote: > Hello, > > found an interesting problem. Perhaps this is the problem? > > In colinux source the file src/colinux/arch/i386/interrupt.c > http://www.henrynestler.com/colinux/source/0.7.1-src/colinux_arch_i386_in= terrupt.c > > See the function "call_intr()". > Is this an execution in stack frame? No, it's a jump to the function pointer, so should be in a "code frame". > What does the "jmp *%0"? > Objdump give that output for this line: > ff 65 fc jmp *0xfffffffc(%ebp) > > Jump to address [ebp-4]. I think, it jumps to contains of [ebp-4] > Is the destination address in an executable page? ebp (the "base pointer") points to the stack frame of the function called, making it easy to retrieve function parameters. In this case it's used to retrieve the function pointer passed as argument. The "jmp" instruction here is a "near" jump, so CS (the code segment) will not change, meaning it will always jump inside the code segment (if it jumps to an invalid position, that is another story, but that would be a bug happening in any PC configuration). I'm not an expert on GNU assembly, but my guess is that it uses the notation of "offset[register]", meaning it's a near jump to [EBP+0xFFFFFFFC], where 0xFFFFFFFC is the 2-complement in 32-bits, that is, -4 (or -(2^32 - 0xFFFFFFFC)). Best regards, ~Nuno Lucas P.S.- If you find that notation a bit strange, try this program in C: int main() { char buf[] =3D "012345"; char *p =3D buf + 4; printf( "c=3D%c\n", 0xFFFFFFFC[buf] ); } ;-) P.P.S- Probably this doesn't work on a 64 bit machine, but it's a standard C notation. > -- > Henry Nestler |
From: Nuno L. <nt...@gm...> - 2006-04-07 00:08:38
|
On 4/7/06, Nuno Lucas <nt...@gm...> wrote: > int main() { > char buf[] =3D "012345"; > char *p =3D buf + 4; > printf( "c=3D%c\n", 0xFFFFFFFC[buf] ); That should have been: printf( "c=3D%c\n", 0xFFFFFFFC[p] ); > } Regards, ~Nuno Lucas |