All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Ingo Molnar <mingo@elte.hu>
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: Fri, 05 Jan 2007 14:50:12 -0800	[thread overview]
Message-ID: <459ED624.1080100@vmware.com> (raw)
In-Reply-To: <20070105223009.GA15369@elte.hu>

Ingo Molnar wrote:
> * 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.

>> But I'm not sure that is technically feasible yet.
>>
>> The kvm code should probably go in kvm.c instead of paravirt.c.
>>     
>
> no. This is fundamental architecture boot code, not module code. kvm.c 
> should eventually go into kernel/ and arch/*/kernel, not the other way 
> around.
>   

What I meant was kvm.c in arch/i386/kernel - as symmetric to the other 
paravirt-ops modules, which live in arch/i386/kernel/vmi.c / lhype.c, 
etc.  Either that, or we should move them to be symmetric, but I don't 
think paravirt.c is the proper place for kvm specific code.


>   
>> Index: linux/drivers/serial/8250.c
>> ===================================================================
>> --- linux.orig/drivers/serial/8250.c
>> +++ linux/drivers/serial/8250.c
>> @@ -1371,7 +1371,7 @@ static irqreturn_t serial8250_interrupt(
>>
>> 		l = l->next;
>>
>> -		if (l == i->head && pass_counter++ > PASS_LIMIT) {
>> +		if (!kvm_paravirt 
>>
>> Is this a bug that might happen under other virtualizations as well, 
>> not just kvm? Perhaps it deserves a disable feature instead of a kvm 
>> specific check.
>>     
>
> 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?


Zach

WARNING: multiple messages have this Message-ID (diff)
From: Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
To: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: kvm-devel
	<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [announce] [patch] KVM paravirtualization for Linux
Date: Fri, 05 Jan 2007 14:50:12 -0800	[thread overview]
Message-ID: <459ED624.1080100@vmware.com> (raw)
In-Reply-To: <20070105223009.GA15369-X9Un+BFzKDI@public.gmane.org>

Ingo Molnar wrote:
> * Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 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.

>> But I'm not sure that is technically feasible yet.
>>
>> The kvm code should probably go in kvm.c instead of paravirt.c.
>>     
>
> no. This is fundamental architecture boot code, not module code. kvm.c 
> should eventually go into kernel/ and arch/*/kernel, not the other way 
> around.
>   

What I meant was kvm.c in arch/i386/kernel - as symmetric to the other 
paravirt-ops modules, which live in arch/i386/kernel/vmi.c / lhype.c, 
etc.  Either that, or we should move them to be symmetric, but I don't 
think paravirt.c is the proper place for kvm specific code.


>   
>> Index: linux/drivers/serial/8250.c
>> ===================================================================
>> --- linux.orig/drivers/serial/8250.c
>> +++ linux/drivers/serial/8250.c
>> @@ -1371,7 +1371,7 @@ static irqreturn_t serial8250_interrupt(
>>
>> 		l = l->next;
>>
>> -		if (l == i->head && pass_counter++ > PASS_LIMIT) {
>> +		if (!kvm_paravirt 
>>
>> Is this a bug that might happen under other virtualizations as well, 
>> not just kvm? Perhaps it deserves a disable feature instead of a kvm 
>> specific check.
>>     
>
> 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?


Zach

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  reply	other threads:[~2007-01-05 22:50 UTC|newest]

Thread overview: 33+ 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 21:52 ` Ingo Molnar
2007-01-05 22:15 ` Zachary Amsden
2007-01-05 22:15   ` Zachary Amsden
2007-01-05 22:30   ` Ingo Molnar
2007-01-05 22:30     ` Ingo Molnar
2007-01-05 22:50     ` Zachary Amsden [this message]
2007-01-05 22:50       ` Zachary Amsden
2007-01-05 23:28       ` Ingo Molnar
2007-01-05 23:02 ` [kvm-devel] " Anthony Liguori
2007-01-06 13:08 ` Pavel Machek
2007-01-06 13:08   ` Pavel Machek
2007-01-07 18:29   ` Christoph Hellwig
2007-01-07 18:29     ` Christoph Hellwig
2007-01-08 18:18   ` Christoph Lameter
2007-01-07 12:20 ` Avi Kivity
2007-01-07 12:20   ` Avi Kivity
2007-01-07 17:42   ` [kvm-devel] " Hollis Blanchard
2007-01-07 17:42     ` Hollis Blanchard
2007-01-07 17:44   ` Ingo Molnar
2007-01-07 17:44     ` Ingo Molnar
2007-01-08  8:22     ` Avi Kivity
2007-01-08  8:22       ` Avi Kivity
2007-01-08  8:39       ` Ingo Molnar
2007-01-08  8:39         ` Ingo Molnar
2007-01-08  9:08         ` Avi Kivity
2007-01-08  9:08           ` Avi Kivity
2007-01-08  9:18           ` Ingo Molnar
2007-01-08  9:18             ` Ingo Molnar
2007-01-08  9:31             ` Avi Kivity
2007-01-08  9:31               ` Avi Kivity
2007-01-08  9:43               ` Ingo Molnar
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=459ED624.1080100@vmware.com \
    --to=zach@vmware.com \
    --cc=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.