mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Kurt Roeckx <Q@ping.be>
Cc: Russell King <rmk@arm.linux.org.uk>,
	Vadim Lebedev <vlebedev@aplio.fr>,
	linux-kernel@vger.kernel.org
Subject: Re: Potenitial security hole in the kernel
Date: Tue, 29 May 2001 02:32:23 +0200	[thread overview]
Message-ID: <20010529023222.C6061@pcep-jamie.cern.ch> (raw)
In-Reply-To: <003601c0e7bf$41953080$0101a8c0@LAP> <20010529001256.F9203@flint.arm.linux.org.uk> <20010529013030.A3381@ping.be> <20010529014635.A3499@ping.be>
In-Reply-To: <20010529014635.A3499@ping.be>; from Q@ping.be on Tue, May 29, 2001 at 01:46:35AM +0200

Kurt Roeckx wrote:
> You should never "return" from userspace to kernelspace.  The
> only way to go from user space to kernel space should be by using
> a system call.

That does actually happen on x86.  The kernel puts a small code fragment
called the "trampoline" on the user mode stack, which is run when the
signal handler returns if it does a normal return.

The trampoline does the system call "sigreturn", and in there the kernel
restores the state of the user mode stack, before returning to user space.

It is possible to avoid the sigreturn system call by setting the
sa_restorer field, and I don't know why Glibc 2.2 doesn't do this.

By the way, the context stored on the stack is entirely a user space
context, however it does include some information from the kernel that
may be useful to user space, such as a page fault address.

If the user space signal handler mucks with the context on its stack,
all that happens is that "sigreturn" will end up restoring a different
user space context and continuing execution with that.  If you set
context.eip to the address of the kernel's panic() function, than the
user space program will simply crash with a SIGSEGV immediately after
"sigreturn" returns to user space.

Mucking with the context in a signal handler is even useful occasionally.

enjoy,
-- Jamie

  reply	other threads:[~2001-05-29  0:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-28 21:43 Vadim Lebedev
2001-05-28 22:21 ` Philip Blundell
2001-05-28 22:26   ` Vadim Lebedev
2001-05-28 22:29 ` Kurt Roeckx
2001-05-28 22:30   ` Vadim Lebedev
2001-05-28 23:15     ` Kurt Roeckx
2001-05-28 22:44 ` Brett Frankenberger
2001-05-28 23:12 ` Russell King
2001-05-28 23:30   ` Kurt Roeckx
2001-05-28 23:46     ` Kurt Roeckx
2001-05-29  0:32       ` Jamie Lokier [this message]
2001-05-29  7:35         ` Chris Wedgwood
2001-05-29 10:14           ` Jamie Lokier

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=20010529023222.C6061@pcep-jamie.cern.ch \
    --to=lk@tantalophile.demon.co.uk \
    --cc=Q@ping.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=vlebedev@aplio.fr \
    /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®