public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ivan Godard" <igodard@pacbell.net>
To: "Pavel Machek" <pavel@ucw.cz>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Kernel support for peer-to-peer protection models...
Date: Sun, 28 Mar 2004 11:56:57 -0800	[thread overview]
Message-ID: <07af01c414fe$d6836300$fc82c23f@pc21> (raw)
In-Reply-To: 20040328185410.GE406@elf.ucw.cz


----- Original Message ----- 
From: "Pavel Machek" <pavel@ucw.cz>
To: "Ivan Godard" <igodard@pacbell.net>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Sunday, March 28, 2004 10:54 AM
Subject: Re: Kernel support for peer-to-peer protection models...


> Hi!
>
> > > Strange system.... If an application does not grant kernel access to
> > > its space, how is kernel supposed to do its job? For example, that
> > > "paranoid DLL" becomes unswappable, then?
> >
> > Pretection is in the *virtual* space, not physical. The physical-page
> > manager (who has the TLB and underlying mapping tables in its space) can
see
> > and deal with any physical address, which in turn has the usual aliasing
> > relationship with virtual addresses. Of course, physical is just one of
the
> > virtual spaces (and is distinguished solely by the one-to-one
> > virtual-physical mapping). So the protection can be penetrated by anyone
who
> > can see the underlying physical page - but that's always true.
>
> Aha, so some part of kernel exist that has "absolute right". Ok, now I
> can imagine that it can work.

The "boot process" comes up with unlimited access to everything and the
virt2phys direct mapped. As it forks procesess it can arbitrarily restrict
their vision, transitively, and set the translation tables any way it wants.
What I've sketched is one model, where a particular virtual space is used to
map physical and the kernel is broken up into distinct address spaces with
protection boundaries between, and each driver and app in ots own space. But
you could emulate a conventoional, with the kernel and the drivers all in
one space (and mutually vulnerable), or others.

> > > If most changes are in arch/, it should be acceptable...
> >
> > I fear that it might be more extensive than that :-)
>
> Well, make patch and lets see... That means that 2.8 needs to be your
> target. If impact outside of arch is not "total rewrite", you might
> have a chance. If it is "total rewrite".... well you just need to be
> very clever.

How badly would the average driver break if it did not have direct data
access to kernal data structures? Calls into the kernel and direct access by
the called functions are OK.

Ivan



  reply	other threads:[~2004-03-28 20:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <048e01c413b3_3c3cae60_fc82c23f@pc21>
2004-03-27 10:34 ` Kernel support for peer-to-peer protection models Pavel Machek
2004-03-28  1:32   ` Ivan Godard
2004-03-28  6:24     ` Pavel Machek
2004-03-28  6:32       ` Ivan Godard
2004-03-28 18:54         ` Pavel Machek
2004-03-28 19:56           ` Ivan Godard [this message]
2004-03-28 20:35             ` Pavel Machek
     [not found] <048e01c413b3$3c3cae60$fc82c23f@pc21.suse.lists.linux.kernel>
2004-03-27  6:29 ` Andi Kleen
2004-03-28 20:21   ` Ivan Godard
2004-03-28 23:14     ` Andi Kleen
2004-03-29  8:09       ` Ivan Godard
2004-03-29 15:36       ` Pavel Machek
2004-03-30 14:06         ` Andi Kleen
2004-03-30 15:09         ` Ivan Godard
2004-03-27  4:23 Ivan Godard
2004-03-29  0:17 ` Paul Mackerras
2004-03-29  3:18   ` Ivan Godard
2004-03-29  3:48     ` Davide Libenzi
2004-03-29  7:52       ` Ivan Godard
2004-03-29 18:45         ` Davide Libenzi
2004-03-29 20:53           ` Ivan Godard

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='07af01c414fe$d6836300$fc82c23f@pc21' \
    --to=igodard@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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