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/
Home Products Support Community News


Re: [Xen-devel] memguard_guard_stack()

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] memguard_guard_stack()
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 28 Apr 2006 17:30:47 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Apr 2006 09:31:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <445258FB.76E4.0078.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <445258FB.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 28 Apr 2006, at 17:03, Jan Beulich wrote:

Is it really intended that the stack size, specifically bumped to 4 pages in include/asm-x86/config.h for x86-64 when debugging, gets shrunk to a single page in memguard_guard_stack()? To me it would seem much more reasonable if indeed only the first page (or at most, the first two pages) was used as a guard page here.

The only reason that the stack is 4 pages on a 64-bit debug build is because we put syscall-entry trampolines at the start of the per-cpu stack area. Therefore simply allocating 2 pages for a debug stack and then removing the mapping of the first page, as we do on i386, does not work -- that would unmap the trampolines! Instead we allocate 4 pages (next power of two) and zap the middle two page mappings. This has the desirable effect of placing the guard between the trampolines and the actual stack (otherwise the trampolines would get overwritten before the guard page gets trodden on!).

It should never be possible for Xen to overflow 4kB of stack. Very little is done in interrupt contexts so we don't have the overflow problems that Linux has suffered.

 -- Keir

Xen-devel mailing list

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