From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH RFC] x86/traps: Improve hypervisor stack
 overflow detection
Date: Fri, 20 Nov 2015 05:23:43 -0700
Message-ID: <564F1EDF02000078000B71CC@prv-mh.provo.novell.com>
References: <1447954456-17855-1-git-send-email-andrew.cooper3@citrix.com>
	<564F09EE02000078000B7118@prv-mh.provo.novell.com>
	<564EFE1C.4090402@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <564EFE1C.4090402@citrix.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Atom2 <ariel.atom2@web2web.at>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

>>> On 20.11.15 at 12:03, <andrew.cooper3@citrix.com> wrote:
> On 20/11/15 10:54, Jan Beulich wrote:
>>>>> On 19.11.15 at 18:34, <andrew.cooper3@citrix.com> wrote:
>>> @@ -394,9 +401,8 @@ void show_stack_overflow(unsigned int cpu, const struct 
> cpu_user_regs *regs)
>>>             (void *)esp_top, (void *)esp_bottom, (void *)esp,
>>>             (void *)per_cpu(init_tss, cpu).esp0);
>>>  
>>> -    /* Trigger overflow trace if %esp is within 512 bytes of the guard page. 
> */
>>> -    if ( ((unsigned long)(esp - esp_top) > 512) &&
>>> -         ((unsigned long)(esp_top - esp) > 512) )
>>> +    /* Trigger overflow trace if %esp is anywhere within the guard page. */
>>> +    if ( (esp & PAGE_MASK) != (esp_top - PAGE_SIZE) )
>> Is this correct? I'd suspect this to be wrong when esp is in the
>> lower of the two primary stack pages.
> 
> If we have hit a double fault from the stack guard pages, one way or
> another %esp is somewhere in the guard page.

But the #DF may be for a reason other than having run into a
stack guard page.

Jan