public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Zachary Amsden <zach@vmware.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
	linux-kernel@vger.kernel.org, Avi Kivity <avi@qumranet.com>
Subject: Re: [announce] [patch] KVM paravirtualization for Linux
Date: Sat, 6 Jan 2007 00:28:53 +0100	[thread overview]
Message-ID: <20070105232853.GA20677@elte.hu> (raw)
In-Reply-To: <459ED624.1080100@vmware.com>


* Zachary Amsden <zach@vmware.com> wrote:

> >>What you really want is more like 
> >>EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
> >>    
> >
> >yep. Not a big issue - what is important is to put the paravirt ops 
> >into the read-only section so that it's somewhat harder for rootkits 
> >to modify. (Also, it needs to be made clear that this is fundamental, 
> >lowlevel system functionality written by people under the GPLv2, so 
> >that if you utilize it beyond its original purpose, using its 
> >internals, you likely create a work derived from the kernel. 
> >Something simple as irq disabling probably doesnt qualify, and that 
> >we exported to modules for a long time, but lots of other details do. 
> >So the existence of paravirt_ops isnt a free-for all.)
> 
> I agree completely.  It would be nice to have a way to make certain 
> kernel structures available, but non-mutable to non-GPL modules.

the thing is, we are not 'making these available to non-GPL modules'. 
The _GPL postfix does not turn the other normal exports from grey into 
white. The _GPL postfix turns exports into almost-black for non-GPL 
modules. The rest is still grey.

in this case, i'd only make local_irq_*() available to modules (of any 
type), not the other paravirt ops. Exporting the whole of paravirt_ops 
was a mistake, and this has to be fixed before 2.6.20. I'll cook up a 
patch.

> >yes - this limit is easily triggered via the KVM/Qemu virtual serial 
> >drivers. You can think of "kvm_paravirt" as "Linux paravirt", it's 
> >just a flag.
> 
> Can't you just test paravirt_enabled() in that case?

yep - i've changed this in my tree.

	Ingo

  reply	other threads:[~2007-01-05 23:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-05 21:52 [announce] [patch] KVM paravirtualization for Linux Ingo Molnar
2007-01-05 22:15 ` Zachary Amsden
2007-01-05 22:30   ` Ingo Molnar
2007-01-05 22:50     ` Zachary Amsden
2007-01-05 23:28       ` Ingo Molnar [this message]
2007-01-05 23:02 ` [kvm-devel] " Anthony Liguori
2007-01-06 13:08 ` Pavel Machek
2007-01-07 18:29   ` Christoph Hellwig
2007-01-08 18:18   ` Christoph Lameter
2007-01-07 12:20 ` Avi Kivity
2007-01-07 17:42   ` [kvm-devel] " Hollis Blanchard
2007-01-07 17:44   ` Ingo Molnar
2007-01-08  8:22     ` Avi Kivity
2007-01-08  8:39       ` Ingo Molnar
2007-01-08  9:08         ` Avi Kivity
2007-01-08  9:18           ` Ingo Molnar
2007-01-08  9:31             ` Avi Kivity
2007-01-08  9:43               ` Ingo Molnar

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=20070105232853.GA20677@elte.hu \
    --to=mingo@elte.hu \
    --cc=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach@vmware.com \
    /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