WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] stack protection in mini-os

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] stack protection in mini-os
From: "Harald Roeck" <hroeck@xxxxxxxxx>
Date: Thu, 31 Jul 2008 13:58:36 -0700
Delivery-date: Thu, 31 Jul 2008 13:59:27 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=1VfG+nlJe9L7ORmIitwtpHZbKluhVKFqIJ8UjLKzIWM=; b=MFlPaox6Eq1I48doQ+reSalyXORAeNwseSbdZSlzuheJLF3PomemZ71KvkXE1cDtGv ZY9M59tsu6a/d6nbu1KtL5V3S1PuLKvA6yxGJkgzdaXmldG22gBgz5L5Oa8Kpae9prxO xtyj5/a6ufcsOQvsEY0csPSNKZuuhJRivSfqw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=TbK6CMo1iRpGhtRpNxf5T94cz/ex3glRK5N/aEJOgO7CwEQ9TRUBqWKOk9yLZ3DNZA Eh7EYuJQ2AkeiCyQW4LRVn/0hyCaUs2xXoIzlmx2skz8oefcpsyg7MiC/iouMmmiWZjy n7+HCh76kV3FV6gp+bHJU3JKz/08xb3oObrXk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hello,

we have a small OS based on mini-os running on a x86_64, and we would
like to implement a stack protection mechanism to catch stack
overflows. All threads are running in kernel mode and we tried to map
out the last stack page. If we overflow the stack and run into the
mapped out stack page xen crashes and the machine reboots. it looks
like xen is trying to push the arguments for the page fault trap onto
the mapped out page. If we mark the last stack page as read-only, only
the guest crashes and the hypervisor is still working. the guest
crashes with the following output on the console:

domain_crash_sync called from entry.S
Domain 2 (vcpu#0) crashed on cpu#1:
----[ Xen-3.1.4-xvm-debug  x86_64  debug=y  Not tainted ]----
CPU:    1
RIP:    e033:[<000000000001583f>]
RFLAGS: 0000000000010246   CONTEXT: guest
rax: 0000000000000000   rbx: 000000000000cb12   rcx: 000000000007b050
rdx: 000000000007b3d0   rsi: 000000000003309f   rdi: 0000000000032caa
rbp: 000000000007b120   rsp: 000000000007aff0   r8:  0000000000000010
r9:  00000000ffffffff   r10: 000000000003309f   r11: 0000000000032ca7
r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
cr3: 00000007ebeea000   cr2: 000000000007aff8
ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
...

fyi: the read only page in this setup was 0x7a000.

so my question: is it possible to set an "alternate" trap stack? We
already tried to set a kernel stack with the stack_switch hypercall,
but this stack is only used when trapping from user context, but we
never enter user context. Or are we missing something? what about
double faults, or the failsafe_callback? we never see any of them.

any suggestions or comments on how we could handle stack overflows are welcome.

thanks,
Harald

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>