> I am sorry, i don't understand how this is related to the semantics of
> e.g. longjmp. But, i am sure my patch solves all overflows. Ingo's patch
> can't catch the overflow which is caught by "int i[1000];" in the handler
> function.
Please read the long explanation I wrote, which Ingo forwarde
Roland McGrath wrote::
>>> Thank you for your detailed explanation and patch. I tested your
>>> patch, unfortunately it can not stop all kinds of overflow.
>> [...]
>>> So, the patch I posted is still needed
>> thanks, i've picked up your fix for x86.git, for 2.6.25 merging.
>
> I just explaine
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> > > Thank you for your detailed explanation and patch. I tested your
> > > patch, unfortunately it can not stop all kinds of overflow.
> > [...]
> > > So, the patch I posted is still needed
> >
> > thanks, i've picked up your fix for x86.git, for 2
> > Thank you for your detailed explanation and patch. I tested your
> > patch, unfortunately it can not stop all kinds of overflow.
> [...]
> > So, the patch I posted is still needed
>
> thanks, i've picked up your fix for x86.git, for 2.6.25 merging.
I just explained that not all overflows wo
* Shi Weihua <[EMAIL PROTECTED]> wrote:
> > When it's the handler function itself or its callees that cause the
> > overflow, rather than the signal handler frame setup alone crossing
> > the boundary, this still won't help. But I don't see any way to
> > distinguish that from the valid longj
On Mon, 26 Nov 2007 19:02:22 -0800 (PST)
Roland McGrath <[EMAIL PROTECTED]> wrote:
> cf http://lkml.org/lkml/2007/10/3/41
>
> To summarize: on Linux, SA_ONSTACK decides whether you are already on
> the signal stack based on the value of the SP at the time of a
> signal. If you are not already in
Roland McGrath wrote::
> cf http://lkml.org/lkml/2007/10/3/41
>
> To summarize: on Linux, SA_ONSTACK decides whether you are already on the
> signal stack based on the value of the SP at the time of a signal. If
> you are not already inside the range, you are not "on the signal stack"
> and so
> thanks Roland for the detailed analysis. I've queued up the patch below
> in the x86 tree. I suspect we can wait with this for v2.6.25, due to
> this being long-standing behavior of Linux? Thus we could observe the
> effects of this patch for a longer time.
It's certainly nothing new. The fa
* Roland McGrath <[EMAIL PROTECTED]> wrote:
[...]
> I think it would be sensible for the signal handler setup code to
> detect when it would itself be causing a stack overflow. Maybe
> something like the following patch (untested). This issue exists in
> the same way on all machines, so idea
cf http://lkml.org/lkml/2007/10/3/41
To summarize: on Linux, SA_ONSTACK decides whether you are already on the
signal stack based on the value of the SP at the time of a signal. If
you are not already inside the range, you are not "on the signal stack"
and so the new signal handler frame starts o
Hi everyone,
If a process uses alternative signal stack by using sigaltstack(),
then that stack overflows and stack wraparound may occur.
Simple explanation:
The accurate esp order is A,B,C,D,...
But now the esp points to A,B,C and A,B,C... dropping into a recursion.
The upper bug and patch about
Mikael Pettersson wrote::
On Thu, 4 Oct 2007 21:47:30 +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 04 Oct 2007 21:33:12 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
KAMEZAWA Hiroyuki wrote::
On Thu, 04 Oct 2007 20:56:14 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
stack.ss_sp = addr + page
On Thu, 4 Oct 2007 21:47:30 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 04 Oct 2007 21:33:12 +0900
> Shi Weihua <[EMAIL PROTECTED]> wrote:
>
> > KAMEZAWA Hiroyuki wrote::
> > > On Thu, 04 Oct 2007 20:56:14 +0900
> > > Shi Weihua <[EMAIL PROTECTED]> wrote:
> > >
> > >> stack.ss_sp = addr + pagesize
On Thu, 04 Oct 2007 21:33:12 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote::
> > On Thu, 04 Oct 2007 20:56:14 +0900
> > Shi Weihua <[EMAIL PROTECTED]> wrote:
> >
> >>stack.ss_sp = addr + pagesize;
> >>stack.ss_flags = 0;
> >>stack.ss_size = pagesize;
> > Here i
KAMEZAWA Hiroyuki wrote::
On Thu, 04 Oct 2007 20:56:14 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
stack.ss_sp = addr + pagesize;
stack.ss_flags = 0;
stack.ss_size = pagesize;
Here is bad.
stack,ss_sp = addr;
stack.ss_flags = 0;
stack.ss_size = pagesize * 2;
[What the
On Thu, 04 Oct 2007 20:56:14 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
> stack.ss_sp = addr + pagesize;
> stack.ss_flags = 0;
> stack.ss_size = pagesize;
Here is bad.
stack,ss_sp = addr;
stack.ss_flags = 0;
stack.ss_size = pagesize * 2;
cheers.
-Kame
-
To unsubscribe from thi
KAMEZAWA Hiroyuki wrote::
On Wed, 3 Oct 2007 15:46:32 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
The proposed kernel signal delivery patch only handles the case
where the /sigframe/ ends up overlapping the end of the altstack.
If the sigframe remains within the altstack boundaries
Mikael Pettersson wrote::
On Wed, 03 Oct 2007 17:06:24 +0900, Shi Weihua wrote:
Fixing alternative signal stack wraparound.
If a process uses alternative signal stack by using sigaltstack()
and that stack overflow, stack wraparound occurs.
This patch checks whether the signal frame is on the al
On Wed, 3 Oct 2007 15:46:32 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> The proposed kernel signal delivery patch only handles the case
> where the /sigframe/ ends up overlapping the end of the altstack.
> If the sigframe remains within the altstack boundaries but the
> user-space s
On Wed, 3 Oct 2007 22:20:46 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 3 Oct 2007 21:40:29 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
> > Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> >
> > > What I don't agree with is the logic itself:
> >
On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > What I don't agree with is the logic itself:
> > - You only catch altstack overflow caused by the kernel pushing
> > a s
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> 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 ow
On Wed, 03 Oct 2007 17:06:24 +0900, Shi Weihua wrote:
> Fixing alternative signal stack wraparound.
>
> If a process uses alternative signal stack by using sigaltstack()
> and that stack overflow, stack wraparound occurs.
> This patch checks whether the signal frame is on the alternative
> stack.
Fixing alternative signal stack wraparound.
If a process uses alternative signal stack by using sigaltstack()
and that stack overflow, stack wraparound occurs.
This patch checks whether the signal frame is on the alternative
stack. If the frame is not on there, kill a signal SIGSEGV to the proces
24 matches
Mail list logo
