mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Chris Wedgwood <cw@f00f.org>
Cc: Kurt Roeckx <Q@ping.be>, 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 12:14:03 +0200	[thread overview]
Message-ID: <20010529121403.A7527@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> <20010529023222.C6061@pcep-jamie.cern.ch> <20010529193540.A7029@metastasis.f00f.org>
In-Reply-To: <20010529193540.A7029@metastasis.f00f.org>; from cw@f00f.org on Tue, May 29, 2001 at 07:35:40PM +1200

Chris Wedgwood wrote:
>     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.
> 
> I actually (ab)used this for userspace paging with mprotect and
> friends.... nasty hack :)

Aye, and it's nice to see that Linux is relatively fast at this.
(See attached table).

Various garbage collectors do this to track dirty pages (clisp, Elk and
Hans Boehm's GC which is now part of the GCC distribution come to mind).
It's a shame this doesn't work for system calls like read(), as they
return EFAULT instead of calling the signal handler.  (It could be made
to work with some effort).

-- Jamie


   Timing measurements
   ===================

   Here are some rough timings to handle a write protection faults and
   change protection from read-only to writable, page by page in
   sequential order.  2000 pages were faulted, in a region of
   memory-mapped /dev/zero.

   The times given are the total running time divided by the number of
   pages, so they including the time to call mprotect to unprotect each
   page.  They are given in microseconds per page, and only the best
   observed time is shown.  The first column is the time to dirty a zero
   page for the first time (the OS must process a second page fault and
   COW/allocate a new page in these cases).  The second column is the
   time to unprotect a page that is already modified, which is the
   typical scenario for an incremental garbage collector.

     133MHz Pentium Linux 2.3.29           85.52      37.13     (page == 4096).
     233MHz dual Pentium II Linux 2.2.17-4 51.17      23.27     (page == 4096).
     233MHz Pentium II Linux 2.4.4         51.15      16.60     (page == 4096).
     300MHz Pentium II Linux 2.4.4         39.84      13.02     (page == 4096).
     366MHz Intel Celeron Linux 2.4.4      38.83      13.02     (page == 4096).
     400MHz Pentium II Linux 2.4.2         35.83      12.46     (page == 4096).
     600MHz Pentium III Linux 2.4.4        33.60       8.12     (page == 4096).
     600MHz Pentium III Linux 2.2.14-5     27.28       7.75     (page == 4096).
     600MHz Pentium III Linux 2.2.17-4     28.62       9.36     (page == 4096).
     PA-RISC HP-UX (which speed?)         108.44      60.34     (page == 4096).
     Sparc Ultra-1 SunOS 5.6              256.69     209.03     (page == 8192).
     Sparc SunOS 5.7 machine #1           158.26     102.26     (page == 8192).
     Sparc SunOS 5.7 machine #2           190.09     139.25     (page == 8192).

      reply	other threads:[~2001-05-29 10:14 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
2001-05-29  7:35         ` Chris Wedgwood
2001-05-29 10:14           ` Jamie Lokier [this message]

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=20010529121403.A7527@pcep-jamie.cern.ch \
    --to=lk@tantalophile.demon.co.uk \
    --cc=Q@ping.be \
    --cc=cw@f00f.org \
    --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®