lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Oct 2007 22:20:46 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	mikpe@...uu.se, linux-kernel@...r.kernel.org, shiwh@...fujitsu.com
Subject: Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound
 occurs

On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:

> On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
> Mikael Pettersson <mikpe@...uu.se> wrote:
> 
> > What I don't agree with is the logic itself:
> > - You only catch altstack overflow caused by the kernel pushing
> >   a sigframe. You don't catch overflow caused by the user-space
> >   signal handler pushing its own stack frame after the sigframe.
> > - SUSv3 specifies the effect of altstack overflow as "undefined".
> > - The overflow problem can be solved in user-space: allocate the
> >   altstack with mmap(), then mprotect() the lowest page to prevent
> >   accesses to it. Any overflow into it, by the kernel's signal
> >   delivery code or by the user-space signal handler, will be caught.
> > 
> > So this patch gets a NAK from me.
> > 
> 
> I can understand what you say, but a program which meets this problem
> cannot be debugged ;(
> 
> gdb just shows infinit loop of function frames and origignal signal frame
> which includes the most important information is overwritten.
> 
there is a difference among user's stack overflow and kernel's.
 - user's stack overflow just breaks memory next to stack frame.
 - kernel's altstack overflow, which this patch tries to fix, breaks
   the bottom of altstack  bacause %esp goes back to the bottom
   of ths altstack when it exceeds altstack range.
   This behavior overwrite orignail stack frame and shows  infinit loop
   of function call to gdb and never stop with 100% cpu usage.
   
Thanks,
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ