From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@muc.de>,
Andrew Morton <akpm@osdl.org>,
virtualization <virtualization@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@sous-sol.org>
Subject: Re: [PATCH] paravirt.h
Date: Tue, 22 Aug 2006 07:59:55 -0700 [thread overview]
Message-ID: <44EB1BEB.60202@goop.org> (raw)
In-Reply-To: <1156254965.27114.17.camel@localhost.localdomain>
Alan Cox wrote:
> It would be nice not to export it at all or to protect it, paravirt_ops
> is a rootkit authors dream ticket. I'm opposed to paravirt_ops until it
> is properly protected, its an unpleasantly large security target if not.
>
Do you have an example of an attack which would become significantly
easier with pv_ops in use? I agree it might make a juicy target, but
surely it is just a matter of degree given that any attacker who can get
to pv_ops can do pretty much anything else.
> It would be a lot safer if we could have the struct paravirt_ops in
> protected read-only const memory space, set it up in the core kernel
> early on in boot when we play "guess todays hypervisor" and then make
> sure it stays in read only (even to kernel) space.
>
Yes, I'd thought about doing something like that, but as Arjan pointed
out, nothing is actually read-only in the kernel when using a 2M
mapping. It's also ameliorated by the fact that some of the entrypoints
are never used at runtime, because the code has been patched inline (but
I don't think it would ever be desirable to patch every entrypoint,
since some are just not worth the effort, complexity or obfuscation
which result from patching).
J
next prev parent reply other threads:[~2006-08-22 14:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 9:35 [PATCH] paravirt.h Rusty Russell
2006-08-10 10:10 ` Rusty Russell
2006-08-10 10:30 ` Andi Kleen
2006-08-10 11:05 ` Rusty Russell
2006-08-10 11:31 ` Andi Kleen
2006-08-10 11:31 ` Andi Kleen
2006-08-10 13:03 ` Zachary Amsden
2006-08-10 15:14 ` Jeremy Fitzhardinge
[not found] ` <44DB54A5.50006@vmware.com>
[not found] ` <44DB6144.2080308@goop.org>
[not found] ` <1155262867.27719.2.camel@localhost.localdomain>
2006-08-11 2:34 ` Jeremy Fitzhardinge
2006-08-10 18:06 ` Jeremy Fitzhardinge
2006-08-19 1:21 ` Adrian Bunk
2006-08-19 2:46 ` Jeremy Fitzhardinge
2006-08-19 2:46 ` Jeremy Fitzhardinge
2006-08-20 8:50 ` Geert Uytterhoeven
2006-08-22 12:56 ` Jeremy Fitzhardinge
2006-08-22 14:08 ` Adrian Bunk
2006-08-22 14:08 ` Adrian Bunk
2006-08-22 13:56 ` Alan Cox
2006-08-22 13:56 ` Alan Cox
2006-08-22 13:44 ` Andi Kleen
2006-08-22 17:16 ` Zachary Amsden
2006-08-22 18:29 ` Arjan van de Ven
2006-08-22 19:30 ` Alan Cox
2006-08-22 19:17 ` Zachary Amsden
2006-08-22 19:26 ` Zachary Amsden
2006-08-22 19:29 ` Arjan van de Ven
2006-08-22 19:43 ` Zachary Amsden
2006-08-22 19:43 ` Zachary Amsden
2006-08-22 20:16 ` Andi Kleen
2006-08-22 22:02 ` Zachary Amsden
2006-08-23 1:55 ` Rusty Russell
2006-08-23 1:55 ` Rusty Russell
2006-08-23 2:12 ` Zachary Amsden
2006-08-23 7:56 ` Arjan van de Ven
2006-08-23 8:44 ` Zachary Amsden
2006-08-23 8:50 ` Andi Kleen
2006-08-23 9:01 ` Zachary Amsden
2006-08-23 9:06 ` Andi Kleen
2006-08-23 9:14 ` Zachary Amsden
2006-08-23 9:20 ` Andi Kleen
2006-08-23 9:36 ` Zachary Amsden
2006-08-23 9:41 ` Andi Kleen
2006-08-23 9:48 ` Zachary Amsden
2006-08-23 9:50 ` Andi Kleen
2006-08-23 10:03 ` Zachary Amsden
2006-08-23 10:03 ` Zachary Amsden
2006-08-23 11:24 ` Andi Kleen
2006-08-23 8:56 ` Arjan van de Ven
2006-08-23 8:18 ` Andi Kleen
2006-08-23 8:18 ` Andi Kleen
2006-08-23 8:38 ` Zachary Amsden
2006-08-22 21:36 ` Alan Cox
2006-08-22 13:45 ` Arjan van de Ven
2006-08-22 13:50 ` Andi Kleen
2006-08-22 14:25 ` Adrian Bunk
2006-08-22 14:25 ` Adrian Bunk
2006-08-22 14:54 ` Andi Kleen
2006-08-22 17:36 ` Zachary Amsden
2006-08-22 18:35 ` Alan Cox
2006-08-22 18:35 ` Alan Cox
2006-08-22 14:59 ` Jeremy Fitzhardinge [this message]
2006-08-22 15:12 ` Arjan van de Ven
2006-08-22 15:12 ` Arjan van de Ven
2006-08-22 15:58 ` Alan Cox
2006-08-22 15:58 ` Alan Cox
2006-08-23 1:35 ` Rusty Russell
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=44EB1BEB.60202@goop.org \
--to=jeremy@goop.org \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.