linux-kernel - Re: [announce] [patch] KVM paravirtualization for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 05 Jan 2007 14:50:12 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	kvm-devel <kvm-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, Avi Kivity <avi@...ranet.com>
Subject: Re: [announce] [patch] KVM paravirtualization for Linux

Ingo Molnar wrote:
> * Zachary Amsden <zach@...are.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/