From: Pavel Machek <pavel@ucw.cz>
To: Ivan Godard <igodard@pacbell.net>
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 20:54:10 +0200 [thread overview]
Message-ID: <20040328185410.GE406@elf.ucw.cz> (raw)
In-Reply-To: <06ea01c4148e$67436c80$fc82c23f@pc21>
Hi!
> > I meant "User Mode Linux" == linux running under linux. Someone
> > probably has an URL.
>
> Sorry - I plead ignorance :-) As the protection is recursive and
> transitive, I suppose that you could do this. When the UMK (user mode
> kernel) went to change the "real" machine it would get a protection fault
> that would be handled by the KMK, emulating the effect. Getting it right and
> also performant would be tricky though - is UML a necessary feature?
No. Its just "nice to have", and it does not support too many
architectures.
> > 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.
> > 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.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
next prev parent reply other threads:[~2004-03-28 18:54 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 [this message]
2004-03-28 19:56 ` Ivan Godard
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=20040328185410.GE406@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=igodard@pacbell.net \
--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