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
next prev parent 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