mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: The well-factored 386
Date: Wed, 30 Jul 2003 09:11:31 +0200	[thread overview]
Message-ID: <20030730071131.GA6282@hh.idb.hist.no> (raw)
In-Reply-To: <20030729161951.GA15889@mail.jlokier.co.uk>

On Tue, Jul 29, 2003 at 05:19:51PM +0100, Jamie Lokier wrote:
> Helge Hafting wrote:
> > > The one thing that made it on-topic for me was his quiet suggestion
> > > that "forreal" mode interrupts are faster, and that it might, perhaps,
> > > be possible to modify a Linux kernel to run in that mode - to take
> > > advantage of the faster interrupts.
> > 
> > That would have to be a kernel for very special use.  The "forreal"
> > mode has protection turned off.  As far as I know, that
> > means any user process can take over the cpu as if
> > it was running in kernel mode.
> 
> There are quite a few embedded systems where that is ok, especially if
> performance is improved.
> 
> Also, I am not sure whether paging still works in "forreal" mode.  If
> it does, kernel memory could still be protected.  Not well enough for
> security, but enough to protect against programming errors.
> 
Paging works even in real mode, afaik. 386es used to emulate
"expanded" memory (a simple bank-switching thing for 286)
by going into protected mode, change the page tables, then
return to real mode with paging still enabled.

So you can probably use paging in "forreal" mode too. I believe
you only get the page table's memory mapping capabilities
though, I don't think you get protection of "kernel" pages
without protection enabled.  

You could still "hide" kernel memory by giving userspace another
page table, but that means page table switching on each
syscall which kills performance worse than interrupt handling
in protecxted mode.

Helge Hafting

  reply	other threads:[~2003-07-30  7:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-28 16:02 Jack Dennon
2003-07-28 16:32 ` David S. Miller
2003-07-28 16:46   ` Andries Brouwer
2003-07-28 16:55     ` David S. Miller
2003-07-28 19:31       ` Herbert Pötzl
2003-07-28 19:41   ` Jamie Lokier
2003-07-29 11:14     ` Helge Hafting
2003-07-29 16:19       ` Jamie Lokier
2003-07-30  7:11         ` Helge Hafting [this message]
2003-07-30 14:05           ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2003-07-29 12:59 John Bradford
2003-07-29 13:32 ` Ville Herva
2003-07-28  8:44 The Well-Factored 386 Rick A. Hohensee
2003-07-28 14:06 ` David S. Miller
2003-07-28 16:36   ` hp
2003-07-28 20:33   ` Rick A. Hohensee
2003-07-28 20:33     ` David S. Miller
2003-07-28 22:27       ` Stephan von Krawczynski
2003-07-28 22:30         ` David S. Miller
2003-07-28 22:58           ` David D. Hagood
2003-07-29 14:32             ` Timothy Miller
2003-07-29 17:21               ` hp
2003-07-29  0:34           ` jw schultz
2003-07-29  1:27             ` Alan Cox
2003-07-29  3:49               ` Larry McVoy
2003-07-29  4:25                 ` Gene Heskett
2003-07-29  4:42                 ` jw schultz
2003-07-29 12:04                 ` Alan Cox
2003-07-29 14:55                 ` Timothy Miller
2003-07-29  8:45           ` hp
2003-07-28 23:11         ` viro
2003-07-29  0:17       ` Brian Raiter

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=20030730071131.GA6282@hh.idb.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.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®