|
|
|
|
|
|
| Author |
Message |
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
 Posted: Fri May 31, 2002 8:36 pm Post subject:
Re: Kernel stack overflow detection?
|
|
|
On Wed, 29 May 2002, Archie Cobbs wrote:
| Quote: | Jake Burkholder writes:
If INVARIANTS doesn't do so already, I'd like to propose to write
up an INVARIANTS check that would validate that the kernel stack
has not overflowed. However I'm curious if anyone has done this
already and/or what the right way to go about it would be. E.g, add
an extra stack page with read-only protection? Any hints appreciated.
-current has a guard page, -stable does not. Also, in -current the
u. area and the pcb were moved so the kernel stack grows away from
them, instead of towards. Either of these changes should be relatively
easy to back port.
|
In -current the U-area and the stack are becoming completely separate,
as the stack and pcb is a per-thread thing and the
remaining parts of the u-area (signal stuff) is a per-process thing.
| Quote: |
Note that on x86 a page fault due a stack overflow will cause a double
fault; the double fault handler uses a task gate which does a hardware
context switch to get off of the bad stack.
So here's a first attempt at a patch for -stable. This patch does
not try to be too ambitious:
- It doesn't move the relative position of the stack in the u. area
- It only works for i386
This is a MFC of the -current option KSTACK_GUARD although it's
done differently (-current and -stable are different anyway in
this area).
It appears that the -current KSTACK_GUARD doesn't mark the page
as read-only (?), whereas this patch does. The advantage is automated
hardware detection of stack overflow, but the disadvantage is
that we have to increase UPAGES by 2 instead of 1 to avoid making
the writable portion of the stack smaller (because before it was
not a multiple of PAGE_SIZE).
|
the guard page should be completely un-mapped.
| Quote: |
Eventually, this option can be applied to other architectures and
moved from conf/options.i386 into conf/options.
Thanks for any reviews/comments.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
--- i386/i386/locore.s Thu Sep 20 02:29:23 2001
+++ i386/i386/locore.s Wed May 29 11:30:20 2002
@@ -813,9 +813,34 @@
fillkptphys($PG_RW)
/* Map proc0's UPAGES in the physical way ... */
+#ifdef KSTACK_GUARD
+ /*
+ * Map the 1st and the 3rd UPAGES pages as writable and the 2nd
+ * page as read-only to detect kernel stack overflows.
+ *
+ * Because of the way fillkptphys() works we have to do this in
+ * three stages: 1st page RW, 2nd page RO, and pages 3-N RW.
+ */
+ movl R(p0upa), %eax
+ movl $1, %ecx
+ fillkptphys($PG_RW)
This was the u-area.. |
ok. though we probably need to check sizeof(strucr user).
| Quote: | +
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ movl $1, %ecx
+ fillkptphys($PG_V)
+
|
This was the guard page..
If we don't call fillkptphys, but just skip over it
I think we'd be ok.. I haven't looked at fillkptphys()
to see if we need to increment something, probably not.
| Quote: | + movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ addl $PAGE_SIZE, %eax
|
| Quote: | + movl $UPAGES, %ecx
+ subl $2, %ecx
|
no, we should split upages into KSTACK_PAGES and USER_PAGES
as we did in -current
| Quote: | + fillkptphys($PG_RW)
+#else
movl R(p0upa), %eax
movl $UPAGES, %ecx
fillkptphys($PG_RW)
+#endif
/* Map ISA hole */
movl $ISA_HOLE_START, %eax
--- i386/i386/pmap.c Thu Jan 3 17:17:33 2002
+++ i386/i386/pmap.c Wed May 29 11:45:39 2002
@@ -890,7 +890,17 @@
/*
* Enter the page into the kernel address space.
*/
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
|
if you just left it alone it would already be so..
| Quote: | + if (i == 1)
+ *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag;
+ else {
+ *(ptek + i) = VM_PAGE_TO_PHYS(m)
+ | PG_RW | PG_V | pgeflag;
+ }
+#else
*(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag;
+#endif
if (oldpte) {
if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) {
invlpg((vm_offset_t) up + i * PAGE_SIZE);
@@ -901,7 +911,15 @@
vm_page_wakeup(m);
vm_page_flag_clear(m, PG_ZERO);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
m->valid = VM_PAGE_BITS_ALL;
}
if (updateneeded)
@@ -997,7 +1015,15 @@
vm_page_wire(m);
vm_page_wakeup(m);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
}
}
--- i386/include/param.h Mon Sep 24 23:14:07 2001
+++ i386/include/param.h Wed May 29 11:34:56 2002
@@ -110,7 +110,11 @@
#define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE)
#define IOPAGES 2 /* pages of i/o permission bitmap */
+#ifdef KSTACK_GUARD
+#define UPAGES 5 /* pages of u-area + kernel stack guard */
+#else
#define UPAGES 3 /* pages of u-area */
+#endif
|
the patches to separate out the u-area and the stack were pretty trivial
check the code in -current.
| Quote: |
/*
* Ceiling on amount of swblock kva space.
--- conf/options.i386 Mon Dec 10 04:17:04 2001
+++ conf/options.i386 Wed May 29 11:32:38 2002
@@ -30,6 +30,9 @@
COMPAT_SVR4 opt_dontuse.h
DEBUG_SVR4 opt_svr4.h
+# Kernel stack guard
+KSTACK_GUARD opt_global.h
+
# i386 SMP options
APIC_IO opt_global.h
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Archie Cobbs
*nix forums beginner
Joined: 21 May 2002
Posts: 39
|
| Posted: Wed May 29, 2002 10:10 pm Post subject:
Re: Kernel stack overflow detection?
|
|
|
Jake Burkholder writes:
| Quote: | -current just leaves the page unmapped which has the same effect
and doesn't waste a physical page for it. This is slightly eaiser
to do if the stack is moved in the u. area.
|
I agree leaving the page unmapped makes more sense. I'm not exactly
sure how to do that but below is an updated patch that attempts to..
Basically I replaced all the PG_V's and PG_MAPPED's in the previous
patch with zeroes. However I think this is still wasting a page of
memory.
I'd appreciate someone who understands this stuff better than me
taking a look at it.
| Quote: | I think sparc64 is the only architecture that uses a guard page
for proc0's kstack; this is worth doing in -current for i386
at least.
|
This patch is supposed to handle proc0 as well (the locore.s patch)...
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
--- i386/i386/locore.s Thu Sep 20 02:29:23 2001
+++ i386/i386/locore.s Wed May 29 14:57:18 2002
@@ -813,9 +813,34 @@
fillkptphys($PG_RW)
/* Map proc0's UPAGES in the physical way ... */
+#ifdef KSTACK_GUARD
+ /*
+ * Map the 1st and the 3rd..Nth UPAGES pages as writable and
+ * leave the 2nd page unmapped to detect kernel stack overflows.
+ *
+ * Because of the way fillkptphys() works we have to do this in
+ * three stages: 1st page RW, 2nd page unmapped, and pages 3-N RW.
+ */
+ movl R(p0upa), %eax
+ movl $1, %ecx
+ fillkptphys($PG_RW)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ movl $1, %ecx
+ fillkptphys($0)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ addl $PAGE_SIZE, %eax
+ movl $UPAGES, %ecx
+ subl $2, %ecx
+ fillkptphys($PG_RW)
+#else
movl R(p0upa), %eax
movl $UPAGES, %ecx
fillkptphys($PG_RW)
+#endif
/* Map ISA hole */
movl $ISA_HOLE_START, %eax
--- i386/i386/pmap.c Thu Jan 3 17:17:33 2002
+++ i386/i386/pmap.c Wed May 29 15:03:24 2002
@@ -890,7 +890,17 @@
/*
* Enter the page into the kernel address space.
*/
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area invalid */
+ if (i == 1)
+ *(ptek + i) = VM_PAGE_TO_PHYS(m) | pgeflag;
+ else {
+ *(ptek + i) = VM_PAGE_TO_PHYS(m)
+ | PG_RW | PG_V | pgeflag;
+ }
+#else
*(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag;
+#endif
if (oldpte) {
if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) {
invlpg((vm_offset_t) up + i * PAGE_SIZE);
@@ -901,7 +911,15 @@
vm_page_wakeup(m);
vm_page_flag_clear(m, PG_ZERO);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area invalid */
+ if (i == 1)
+ vm_page_flag_set(m, 0);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
m->valid = VM_PAGE_BITS_ALL;
}
if (updateneeded)
@@ -997,7 +1015,15 @@
vm_page_wire(m);
vm_page_wakeup(m);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area invalid */
+ if (i == 1)
+ vm_page_flag_set(m, 0);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
}
}
--- i386/include/param.h Mon Sep 24 23:14:07 2001
+++ i386/include/param.h Wed May 29 11:34:56 2002
@@ -110,7 +110,11 @@
#define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE)
#define IOPAGES 2 /* pages of i/o permission bitmap */
+#ifdef KSTACK_GUARD
+#define UPAGES 5 /* pages of u-area + kernel stack guard */
+#else
#define UPAGES 3 /* pages of u-area */
+#endif
/*
* Ceiling on amount of swblock kva space.
--- conf/options.i386 Mon Dec 10 04:17:04 2001
+++ conf/options.i386 Wed May 29 11:32:38 2002
@@ -30,6 +30,9 @@
COMPAT_SVR4 opt_dontuse.h
DEBUG_SVR4 opt_svr4.h
+# Kernel stack guard
+KSTACK_GUARD opt_global.h
+
# i386 SMP options
APIC_IO opt_global.h
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Archie Cobbs
*nix forums beginner
Joined: 21 May 2002
Posts: 39
|
| Posted: Wed May 29, 2002 7:20 pm Post subject:
Re: Kernel stack overflow detection?
|
|
|
Jake Burkholder writes:
| Quote: | If INVARIANTS doesn't do so already, I'd like to propose to write
up an INVARIANTS check that would validate that the kernel stack
has not overflowed. However I'm curious if anyone has done this
already and/or what the right way to go about it would be. E.g, add
an extra stack page with read-only protection? Any hints appreciated.
-current has a guard page, -stable does not. Also, in -current the
u. area and the pcb were moved so the kernel stack grows away from
them, instead of towards. Either of these changes should be relatively
easy to back port.
Note that on x86 a page fault due a stack overflow will cause a double
fault; the double fault handler uses a task gate which does a hardware
context switch to get off of the bad stack.
|
So here's a first attempt at a patch for -stable. This patch does
not try to be too ambitious:
- It doesn't move the relative position of the stack in the u. area
- It only works for i386
This is a MFC of the -current option KSTACK_GUARD although it's
done differently (-current and -stable are different anyway in
this area).
It appears that the -current KSTACK_GUARD doesn't mark the page
as read-only (?), whereas this patch does. The advantage is automated
hardware detection of stack overflow, but the disadvantage is
that we have to increase UPAGES by 2 instead of 1 to avoid making
the writable portion of the stack smaller (because before it was
not a multiple of PAGE_SIZE).
Eventually, this option can be applied to other architectures and
moved from conf/options.i386 into conf/options.
Thanks for any reviews/comments.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
--- i386/i386/locore.s Thu Sep 20 02:29:23 2001
+++ i386/i386/locore.s Wed May 29 11:30:20 2002
@@ -813,9 +813,34 @@
fillkptphys($PG_RW)
/* Map proc0's UPAGES in the physical way ... */
+#ifdef KSTACK_GUARD
+ /*
+ * Map the 1st and the 3rd UPAGES pages as writable and the 2nd
+ * page as read-only to detect kernel stack overflows.
+ *
+ * Because of the way fillkptphys() works we have to do this in
+ * three stages: 1st page RW, 2nd page RO, and pages 3-N RW.
+ */
+ movl R(p0upa), %eax
+ movl $1, %ecx
+ fillkptphys($PG_RW)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ movl $1, %ecx
+ fillkptphys($PG_V)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ addl $PAGE_SIZE, %eax
+ movl $UPAGES, %ecx
+ subl $2, %ecx
+ fillkptphys($PG_RW)
+#else
movl R(p0upa), %eax
movl $UPAGES, %ecx
fillkptphys($PG_RW)
+#endif
/* Map ISA hole */
movl $ISA_HOLE_START, %eax
--- i386/i386/pmap.c Thu Jan 3 17:17:33 2002
+++ i386/i386/pmap.c Wed May 29 11:45:39 2002
@@ -890,7 +890,17 @@
/*
* Enter the page into the kernel address space.
*/
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag;
+ else {
+ *(ptek + i) = VM_PAGE_TO_PHYS(m)
+ | PG_RW | PG_V | pgeflag;
+ }
+#else
*(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag;
+#endif
if (oldpte) {
if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) {
invlpg((vm_offset_t) up + i * PAGE_SIZE);
@@ -901,7 +911,15 @@
vm_page_wakeup(m);
vm_page_flag_clear(m, PG_ZERO);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
m->valid = VM_PAGE_BITS_ALL;
}
if (updateneeded)
@@ -997,7 +1015,15 @@
vm_page_wire(m);
vm_page_wakeup(m);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
}
}
--- i386/include/param.h Mon Sep 24 23:14:07 2001
+++ i386/include/param.h Wed May 29 11:34:56 2002
@@ -110,7 +110,11 @@
#define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE)
#define IOPAGES 2 /* pages of i/o permission bitmap */
+#ifdef KSTACK_GUARD
+#define UPAGES 5 /* pages of u-area + kernel stack guard */
+#else
#define UPAGES 3 /* pages of u-area */
+#endif
/*
* Ceiling on amount of swblock kva space.
--- conf/options.i386 Mon Dec 10 04:17:04 2001
+++ conf/options.i386 Wed May 29 11:32:38 2002
@@ -30,6 +30,9 @@
COMPAT_SVR4 opt_dontuse.h
DEBUG_SVR4 opt_svr4.h
+# Kernel stack guard
+KSTACK_GUARD opt_global.h
+
# i386 SMP options
APIC_IO opt_global.h
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed May 29, 2002 6:18 pm Post subject:
Re: Kernel stack overflow detection?
|
|
|
Archie Cobbs wrote:
| Quote: | + * Map the 1st and the 3rd UPAGES pages as writable and the 2nd
+ * page as read-only to detect kernel stack overflows.
+ *
+ * Because of the way fillkptphys() works we have to do this in
+ * three stages: 1st page RW, 2nd page RO, and pages 3-N RW.
+ */
|
IMO, the 2nd page should be unmapped, not mapped R/O.
With it mapped R/O, you won't detect reads of auto variables in a
terminal function which are not used for a given code path, but
might be used for a different code path.
You might be able to 100% trust the compiler for "might be used
before initialized".
Also, while it's not a problem for most people, mapping it R/O
on the 386 won't actually do anything when it comes to writing it
from kernel space (no fault will be generated because the 386 lacks
this capability, even if it lets you map that way). Unmapping it
will ensure a fault, even on the 386.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jake Burkholder
*nix forums beginner
Joined: 27 Mar 2002
Posts: 12
|
| Posted: Wed May 29, 2002 6:04 pm Post subject:
Re: Kernel stack overflow detection?
|
|
|
Apparently, On Wed, May 29, 2002 at 12:20:45PM -0700,
Archie Cobbs said words to the effect of;
| Quote: | Jake Burkholder writes:
If INVARIANTS doesn't do so already, I'd like to propose to write
up an INVARIANTS check that would validate that the kernel stack
has not overflowed. However I'm curious if anyone has done this
already and/or what the right way to go about it would be. E.g, add
an extra stack page with read-only protection? Any hints appreciated.
-current has a guard page, -stable does not. Also, in -current the
u. area and the pcb were moved so the kernel stack grows away from
them, instead of towards. Either of these changes should be relatively
easy to back port.
Note that on x86 a page fault due a stack overflow will cause a double
fault; the double fault handler uses a task gate which does a hardware
context switch to get off of the bad stack.
So here's a first attempt at a patch for -stable. This patch does
not try to be too ambitious:
- It doesn't move the relative position of the stack in the u. area
- It only works for i386
This is a MFC of the -current option KSTACK_GUARD although it's
done differently (-current and -stable are different anyway in
this area).
It appears that the -current KSTACK_GUARD doesn't mark the page
as read-only (?), whereas this patch does. The advantage is automated
hardware detection of stack overflow, but the disadvantage is
that we have to increase UPAGES by 2 instead of 1 to avoid making
the writable portion of the stack smaller (because before it was
not a multiple of PAGE_SIZE).
|
-current just leaves the page unmapped which has the same effect
and doesn't waste a physical page for it. This is slightly eaiser
to do if the stack is moved in the u. area.
I think sparc64 is the only architecture that uses a guard page
for proc0's kstack; this is worth doing in -current for i386
at least.
| Quote: |
Eventually, this option can be applied to other architectures and
moved from conf/options.i386 into conf/options.
Thanks for any reviews/comments.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
--- i386/i386/locore.s Thu Sep 20 02:29:23 2001
+++ i386/i386/locore.s Wed May 29 11:30:20 2002
@@ -813,9 +813,34 @@
fillkptphys($PG_RW)
/* Map proc0's UPAGES in the physical way ... */
+#ifdef KSTACK_GUARD
+ /*
+ * Map the 1st and the 3rd UPAGES pages as writable and the 2nd
+ * page as read-only to detect kernel stack overflows.
+ *
+ * Because of the way fillkptphys() works we have to do this in
+ * three stages: 1st page RW, 2nd page RO, and pages 3-N RW.
+ */
+ movl R(p0upa), %eax
+ movl $1, %ecx
+ fillkptphys($PG_RW)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ movl $1, %ecx
+ fillkptphys($PG_V)
+
+ movl R(p0upa), %eax
+ addl $PAGE_SIZE, %eax
+ addl $PAGE_SIZE, %eax
+ movl $UPAGES, %ecx
+ subl $2, %ecx
+ fillkptphys($PG_RW)
+#else
movl R(p0upa), %eax
movl $UPAGES, %ecx
fillkptphys($PG_RW)
+#endif
/* Map ISA hole */
movl $ISA_HOLE_START, %eax
--- i386/i386/pmap.c Thu Jan 3 17:17:33 2002
+++ i386/i386/pmap.c Wed May 29 11:45:39 2002
@@ -890,7 +890,17 @@
/*
* Enter the page into the kernel address space.
*/
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag;
+ else {
+ *(ptek + i) = VM_PAGE_TO_PHYS(m)
+ | PG_RW | PG_V | pgeflag;
+ }
+#else
*(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag;
+#endif
if (oldpte) {
if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) {
invlpg((vm_offset_t) up + i * PAGE_SIZE);
@@ -901,7 +911,15 @@
vm_page_wakeup(m);
vm_page_flag_clear(m, PG_ZERO);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
m->valid = VM_PAGE_BITS_ALL;
}
if (updateneeded)
@@ -997,7 +1015,15 @@
vm_page_wire(m);
vm_page_wakeup(m);
+#ifdef KSTACK_GUARD
+ /* Make bottom page of stack area un-writable */
+ if (i == 1)
+ vm_page_flag_set(m, PG_MAPPED);
+ else
+ vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#else
vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE);
+#endif
}
}
--- i386/include/param.h Mon Sep 24 23:14:07 2001
+++ i386/include/param.h Wed May 29 11:34:56 2002
@@ -110,7 +110,11 @@
#define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE)
#define IOPAGES 2 /* pages of i/o permission bitmap */
+#ifdef KSTACK_GUARD
+#define UPAGES 5 /* pages of u-area + kernel stack guard */
+#else
#define UPAGES 3 /* pages of u-area */
+#endif
/*
* Ceiling on amount of swblock kva space.
--- conf/options.i386 Mon Dec 10 04:17:04 2001
+++ conf/options.i386 Wed May 29 11:32:38 2002
@@ -30,6 +30,9 @@
COMPAT_SVR4 opt_dontuse.h
DEBUG_SVR4 opt_svr4.h
+# Kernel stack guard
+KSTACK_GUARD opt_global.h
+
# i386 SMP options
APIC_IO opt_global.h
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jake Burkholder
*nix forums beginner
Joined: 27 Mar 2002
Posts: 12
|
| Posted: Wed May 29, 2002 12:18 am Post subject:
Re: Kernel stack overflow detection?
|
|
|
Apparently, On Tue, May 28, 2002 at 04:49:17PM -0700,
Archie Cobbs said words to the effect of;
| Quote: | Hi,
Got a question and a proposal... I'm trying to track down a mysterious
bug and one possible theory is a kernel stack overflow (I've bloated
the kernel with a bunch of custom code). This is in FreeBSD-stable.
The question is: does INVARIANTS do anything to detect this? If not,
what would be the "expected" behavior of such a bug?
If INVARIANTS doesn't do so already, I'd like to propose to write
up an INVARIANTS check that would validate that the kernel stack
has not overflowed. However I'm curious if anyone has done this
already and/or what the right way to go about it would be. E.g, add
an extra stack page with read-only protection? Any hints appreciated.
|
-current has a guard page, -stable does not. Also, in -current the
u. area and the pcb were moved so the kernel stack grows away from
them, instead of towards. Either of these changes should be relatively
easy to back port.
Note that on x86 a page fault due a stack overflow will cause a double
fault; the double fault handler uses a task gate which does a hardware
context switch to get off of the bad stack.
Jake
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Archie Cobbs
*nix forums beginner
Joined: 21 May 2002
Posts: 39
|
| Posted: Tue May 28, 2002 11:49 pm Post subject:
Kernel stack overflow detection?
|
|
|
Hi,
Got a question and a proposal... I'm trying to track down a mysterious
bug and one possible theory is a kernel stack overflow (I've bloated
the kernel with a bunch of custom code). This is in FreeBSD-stable.
The question is: does INVARIANTS do anything to detect this? If not,
what would be the "expected" behavior of such a bug?
If INVARIANTS doesn't do so already, I'd like to propose to write
up an INVARIANTS check that would validate that the kernel stack
has not overflowed. However I'm curious if anyone has done this
already and/or what the right way to go about it would be. E.g, add
an extra stack page with read-only protection? Any hints appreciated.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:03 am | All times are GMT
|
|
Credit Cards | Unsecured Credit Cards | Looking for Credit Cards? | Prepaid Credit Cards | Movies download
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
