From: Shi Weihua <shiwh@cn.fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mikael Pettersson <mikpe@it.uu.se>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs
Date: Thu, 04 Oct 2007 20:56:14 +0900 [thread overview]
Message-ID: <4704D4DE.8010805@cn.fujitsu.com> (raw)
In-Reply-To: <20071003232509.929160f1.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote::
> On Wed, 3 Oct 2007 15:46:32 +0200 (MEST)
> Mikael Pettersson <mikpe@it.uu.se> 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 signal handler adds an /ordinary stack frame/ that
>> moves SP beyond the altstack limit, then the kernel patch solves
>> nothing and recursive signals will cause altstack wraparound.
>>
>> On the other hand, the user-space technique of making the lowest
>> page(s) in the altstack inaccessible handles both cases of overflow.
>>
> Hmm, okay. Then, this fix is not enough. I see.
> I'll consider how to eduacate users.
Excuse me. What will Mr.Kamezawa educate users? How to use sigaltstack?
Following is about using mmap/mprotect. In the previous mail(just now), I have said the same
thing.Now I say it again in detailed.
Mikael has told us user'd better to use mmap/mprotect. So I tried to use mmap/mprotect in my test code.
I want to mprotect() the place from mid to low, and hope it stop the overflow.
high
|
| enable to access
|
mid
|
| disable to access
|
low
I hope the kernel catch it when the esp beyond the boundaries(mid) in user-space.
But the altstack wraparound still occurs.
begin = 0xb7fec000
end = 0xb7fee000
esp = 0xb7fedce0
1
esp = 0xb7fed9e0
2
esp = 0xb7fed6e0
3
esp = 0xb7fedce0 <- wraparound
4
...
Fortunately, when I reuse the patch, wraparound disappeared. Even if I activate the code *1(please
refer to the following test code).
So I think we need the patch, in the same time,we advice the user it's better to use mmap/mprotect.
-----------------------------------------------------------
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>
#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
volatile int counter = 0;
#ifdef __i386__
void print_esp()
{
unsigned long esp;
__asm__ __volatile__("movl %%esp, %0":"=g"(esp));
printf("esp = 0x%08lx\n", esp);
}
#endif
static void segv_handler()
{
#ifdef __i386__
print_esp();
#endif
// int i[1000]; //*1
int *c = NULL;
counter++;
printf("%d\n", counter);
*c = 1; // SEGV
}
int main()
{
int *c = NULL;
int pagesize;
char *addr;
stack_t stack;
struct sigaction action;
pagesize = sysconf(_SC_PAGE_SIZE);
if (pagesize == -1)
die("sysconf");
addr = mmap(NULL, pagesize * 2, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (addr == MAP_FAILED)
die("mmap");
printf("begin = 0x%08lx\n", addr);
printf("end = 0x%08lx\n", addr + pagesize * 2);
if (mprotect(addr, pagesize, PROT_NONE) == -1)
die("mprotect");
stack.ss_sp = addr + pagesize;
stack.ss_flags = 0;
stack.ss_size = pagesize;
int error = sigaltstack(&stack, NULL);
if (error) {
printf("Failed to use sigaltstack!\n");
return -1;
}
memset(&action, 0, sizeof(action));
action.sa_handler = segv_handler;
action.sa_flags = SA_ONSTACK | SA_NODEFER;
sigemptyset(&action.sa_mask);
sigaction(SIGSEGV, &action, NULL);
*c = 0; //SEGV
return 0;
}
-----------------------------------------------------------
Any suggestion?
Thanks
Shi Weihua
>
> Thanks,
> -Kame
>
>
>
next prev parent reply other threads:[~2007-10-04 11:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-03 13:46 [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs Mikael Pettersson
2007-10-03 14:25 ` KAMEZAWA Hiroyuki
2007-10-04 11:56 ` Shi Weihua [this message]
2007-10-04 12:17 ` KAMEZAWA Hiroyuki
2007-10-04 12:33 ` Shi Weihua
2007-10-04 12:47 ` KAMEZAWA Hiroyuki
[not found] <474CF7D5.6010702@cn.fujitsu.com>
2007-11-28 6:07 ` Fw: " Shi Weihua
2007-12-04 13:02 ` Ingo Molnar
2007-12-04 21:52 ` Roland McGrath
2007-12-04 21:57 ` Ingo Molnar
2007-12-05 5:22 ` Shi Weihua
2007-12-05 5:36 ` Roland McGrath
[not found] <20071126143317.dd884128.akpm@linux-foundation.org>
[not found] ` <20071126230242.GA9623@elte.hu>
2007-11-27 3:02 ` Fw: " Roland McGrath
2007-11-27 22:57 ` Arjan van de Ven
-- strict thread matches above, loose matches on Subject: below --
2007-10-04 13:08 Mikael Pettersson
2007-10-05 0:55 ` Shi Weihua
2007-10-03 12:20 Mikael Pettersson
2007-10-03 12:40 ` KAMEZAWA Hiroyuki
2007-10-03 13:20 ` KAMEZAWA Hiroyuki
2007-10-04 11:02 ` Shi Weihua
2007-10-03 8:06 Shi Weihua
2007-11-19 2:15 ` Shi Weihua
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4704D4DE.8010805@cn.fujitsu.com \
--to=shiwh@cn.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox