Cooperative Linux

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?
>

On 4/4/06, Henry Nestler <Henry.Ne@...> 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

On 4/7/06, Nuno Lucas <ntlucas@...> 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

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

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/

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: colinux-devel@...
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
coLinux-devel@...
https://lists.sourceforge.net/lists/listinfo/colinux-devel

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

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

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

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
>coLinux-devel@...
>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@....

----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@... -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@...'
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@... 
-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@...'
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
dschulz@...

Hello Dave,

Dave Schulz wrote:
> [...]
> when CoMake tries to execute  the following lines, the linker can't find 
> __VirtualProtect@....

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

Henry Nestler schrieb:
> Hello Dave,
> 
> Dave Schulz wrote:
>> [...]
>> when CoMake tries to execute  the following lines, the linker can't find 
>> __VirtualProtect@....
> 
> 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

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

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

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