From: Andrea Arcangeli <andrea@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Leif Sawyer <lsawyer@gci.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: FW: i386 Linux kernel DoS
Date: Thu, 14 Nov 2002 20:00:14 +0100 [thread overview]
Message-ID: <20021114190014.GQ31697@dualathlon.random> (raw)
In-Reply-To: <Pine.LNX.4.44.0211140956480.1340-100000@home.transmeta.com>
On Thu, Nov 14, 2002 at 10:12:53AM -0800, Linus Torvalds wrote:
>
> Ok, the reason for this one is that we don't really emulate a
> trap/interrupt gate correctly when taking a lcall. We _do_ set up the
> stack to be identical, but a real trap/interrupt will also clear TF and NT
actually TF should cleared implicitly in the do_debug or it could get
the single step trap before you can clear TF explicitly in the entry.S.
but it's certainly zerocost to clear it explicitly there too just to
remeber it's one of the bits not cleared implicitly in hardware when
entering via lcall. However in 2.5 it seems the clear_TF in do_debug is
still missing.
basically you need to add this check in do_debug too:
--- x/arch/i386/kernel/traps.c.~1~ Fri Aug 9 14:52:06 2002
+++ x/arch/i386/kernel/traps.c Thu Nov 14 19:57:42 2002
@@ -514,10 +514,14 @@ asmlinkage void do_debug(struct pt_regs
{
unsigned int condition;
struct task_struct *tsk = current;
+ unsigned long eip = regs->eip;
siginfo_t info;
__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));
+ if ((eip >=PAGE_OFFSET) && (regs->eflags & TF_MASK))
+ goto clear_TF;
+
/* Mask out spurious debug traps due to lazy DR7 setting */
if (condition & (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3)) {
if (!tsk->thread.debugreg[7])
or maybe I'm missing something and 2.5 fixes it in another way that I
didn't notice.
> in EFLAGS on entry to the kernel (_after_ having saved the value off), and
> our emulation code didn't do that.
>
> So when we returned with an "iret", we had NT set in EFLAGS, causing the
> iret to do all the wrong things.
Yep.
Andrea
next prev parent reply other threads:[~2002-11-14 18:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-12 23:28 FW: i386 Linux kernel DoS Leif Sawyer
2002-11-12 23:31 ` Christoph Hellwig
2002-11-13 0:10 ` Alan Cox
2002-11-13 23:38 ` Jirka Kosina
2002-11-13 23:58 ` Chris Wright
2002-11-14 9:08 ` Helge Hafting
2002-11-14 3:05 ` Andrea Arcangeli
2002-11-14 4:10 ` Andrea Arcangeli
2002-11-14 18:12 ` Linus Torvalds
2002-11-14 19:00 ` Andrea Arcangeli [this message]
2002-11-14 19:17 ` Linus Torvalds
2002-11-15 2:13 ` Andrea Arcangeli
2002-11-14 20:06 ` Petr Vandrovec
2002-11-16 19:33 ` Krzysiek Taraszka
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=20021114190014.GQ31697@dualathlon.random \
--to=andrea@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsawyer@gci.com \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
/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