From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 2.5.74] Signal stack safety #2 i386 specific
Date: Mon, 7 Jul 2003 11:30:25 +0200 [thread overview]
Message-ID: <20030707093025.GA2598@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20030706125103.GB23341@wohnheim.fh-wedel.de>
On Sun, 6 July 2003 14:51:03 +0200, Jörn Engel wrote:
>
> My current best idea is to check, whether the stack pointer is valid
> before going to the signal stack. As long as it points to memory that
> is writable for the current process, things are not completely
> hopeless. When the stack is totally broken, kill that cancer cell.
Also stupid. People use a segfault handler on a signal stack,
*because* the previous stack may be broken.
Since any trick we try appears to (possibly) break some existing
software, the next idea is to add yet another flag to signal.h. With
this, the user can decide whether he want to get extra safety or not.
Comments?
Jörn
--
The only real mistake is the one from which we learn nothing.
-- John Powell
--- linux-2.5.74/arch/i386/kernel/signal.c~ss_i386 2003-07-07 10:30:30.000000000 +0200
+++ linux-2.5.74/arch/i386/kernel/signal.c 2003-07-07 10:31:09.000000000 +0200
@@ -181,6 +181,9 @@
}
}
+ if (sas_ss_flags(regs->esp) == 0)
+ current->flags &= ~PF_SS_ACTIVE;
+
err |= __get_user(*peax, &sc->eax);
return err;
@@ -317,9 +320,23 @@
esp = regs->esp;
/* This is the X/Open sanctioned signal stack switching. */
- if (ka->sa.sa_flags & SA_ONSTACK) {
- if (sas_ss_flags(esp) == 0)
- esp = current->sas_ss_sp + current->sas_ss_size;
+ if ((ka->sa.sa_flags & SA_ONSTACK) && (sas_ss_flags(esp) == 0)) {
+ /* If we have switches to the signal stack before,
+ * something bad has happened to it, asking for a
+ * segmentation fault.
+ * If not, remember it for the next time
+ */
+ if ((ka->sa.sa_flags & SA_KERNEL_RET) &&
+ (current->flags & PF_SS_ACTIVE)) {
+ ka->sa.sa_handler = SIG_DFL;
+ force_sig(SIGSEGV, current);
+ /* XXX would it be simpler to return some broken
+ * value like NULL and have the calling function
+ * signal the segv?
+ */
+ }
+ current->flags |= PF_SS_ACTIVE;
+ esp = current->sas_ss_sp + current->sas_ss_size;
}
/* This is the legacy signal stack switching. */
--- linux-2.5.74/include/asm-i386/signal.h~ss_i386 2003-07-07 10:30:30.000000000 +0200
+++ linux-2.5.74/include/asm-i386/signal.h 2003-07-07 11:29:42.000000000 +0200
@@ -76,6 +76,8 @@
* SA_FLAGS values:
*
* SA_ONSTACK indicates that a registered stack_t will be used.
+ * SA_KERNEL_RET indices that the handler returns through the kernel, not
+ * with longjmp or similar.
* SA_INTERRUPT is a no-op, but left due to historical reasons. Use the
* SA_RESTART flag to get restarting signals (which were the default long ago)
* SA_NOCLDSTOP flag to turn off SIGCHLD when children stop.
@@ -89,6 +91,7 @@
#define SA_NOCLDSTOP 0x00000001u
#define SA_NOCLDWAIT 0x00000002u
#define SA_SIGINFO 0x00000004u
+#define SA_KERNEL_RET 0x01000000u
#define SA_ONSTACK 0x08000000u
#define SA_RESTART 0x10000000u
#define SA_NODEFER 0x40000000u
next prev parent reply other threads:[~2003-07-07 9:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-03 20:24 [PATCH 2.5.73] Fix broken signal optimization for i386 Jörn Engel
2003-07-04 17:43 ` Jörn Engel
2003-07-04 17:45 ` [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE Jörn Engel
2003-07-04 17:51 ` [PATCH 2.5.73] Signal stack fixes #2 i386-specific Jörn Engel
2003-07-04 17:54 ` [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE Jörn Engel
2003-07-04 17:58 ` [PATCH 2.5.73] Signal handling fix for ppc Jörn Engel
2003-07-04 23:26 ` Paul Mackerras
2003-07-05 7:33 ` Jörn Engel
2003-07-04 23:18 ` [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE Paul Mackerras
2003-07-05 7:39 ` Jörn Engel
2003-07-06 8:47 ` Paul Mackerras
2003-07-06 10:17 ` Jörn Engel
2003-07-07 11:29 ` Paul Mackerras
2003-07-07 11:58 ` Jörn Engel
2003-07-07 11:33 ` Paul Mackerras
2003-07-07 11:46 ` Jörn Engel
2003-07-04 19:21 ` Linus Torvalds
2003-07-04 19:38 ` Jörn Engel
2003-07-04 20:06 ` Linus Torvalds
2003-07-04 20:18 ` Jörn Engel
2003-07-05 0:39 ` Linus Torvalds
2003-07-05 7:30 ` Jörn Engel
2003-07-05 10:44 ` Jörn Engel
2003-07-05 17:16 ` Linus Torvalds
2003-07-06 12:51 ` Jörn Engel
2003-07-07 9:30 ` Jörn Engel [this message]
2003-07-05 17:06 ` Jamie Lokier
2003-07-06 1:27 ` Eric W. Biederman
2003-07-04 19:39 ` Davide Libenzi
2003-07-04 20:24 ` Jörn Engel
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=20030707093025.GA2598@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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
all inboxes | Powered by JetHome®