All of lore.kernel.org
 help / color / mirror / Atom feed
From: Asdo <asdo@shiftmail.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: kvm@vger.kernel.org
Subject: Re: Doubt on KVM-88 vulnerabilities
Date: Tue, 10 Nov 2009 15:19:53 +0100	[thread overview]
Message-ID: <4AF97689.1070503@shiftmail.org> (raw)
In-Reply-To: <4AF95690.1050208@msgid.tls.msk.ru>

Thanks for your reply,
sorry to get you angry, but there are still things which are not clear 
to me.

Please note that if you try to search "kvm kvm-kmod kvm-qemu" with 
google you will discover that basically nothing comes out telling you 
the differences between the three. Now searching within this mailing 
list I did find ONE thread that tells the thing
http://www.spinics.net/lists/kvm/msg23341.html
however it does not explain a few things that you also do not explain in 
this reply:

1) Why the kernel module should better be kept that of kernel? I have 
machines with 2.6.24 kernel, that's years ago, how is it possible that 
such kernel module is better than what I can compile from kvm-88? (As I 
explained I am not willing to upgrade the whole kernel on a production 
machine to avoid introduce new issues, but KVM itself has evolved a lot 
in the same time, I bet in every aspect, if I can get a stable release)

2) Even in your example below, I don't understand: 2.6.30 was released 
in june 10, kvm-88 was released in July 12th, why should the kvm kernel 
module in 2.6.30 be "more recent"?

3) Everyone here mentions to upgrade the userspace part only. That 
sounds strange to me because in all kernelmode+usermode applications I 
have seen up to now, the usermode part was just there to drive the 
kernelmode part (basically parse commandline parameters and communicate 
them to the kernel) Ok I understand that in KVM also the emulated 
devices run in userspace so ok probably also the emulated devices might 
improve if I upgrade the userspace part, however the most important 
stuff, that causes a virtual machine to crash or to work correctly, is 
the kernelmode stuff. Or at least this is what I thought: is this wrong?

Also see other questions below -->

Michael Tokarev wrote:
> There's no need to compile kvm _modules_ if you're using recent-enough
> kernel.
Yeah except that this is in contrast with what I have written in my 
previous post: I don't have a recent kernel (don't know the definition 
of "recent-enough") and I am not really willing to upgrade *all* the kernel.

> I _fail_ to see why people are still using older and buggy
> modules from kvm-88 with kernels >=2.6.30 where these modules are more
> recent and with bugfixes.  But that's entirely different point.
see above question 2

>> However for compiling from source I would need to know which versions 
>> of KVM are "stable" and which are not.
>
> qemu-kvm-n.nn.n are stable releases.  First stable release (0.10)
> already contained the fixes you mentioned.  They're versioned exactly
> like kernel - 0.10.0, 0.10.1, ..., 0.10.6 like 2.6.27 .. 2.6.26.36 or
> what it is now.  Current qemu-kvm is 0.11.0.
>
Great! That is the stable userspace then.

But what about stable kernel modules?

Are these the kvm-kmod's?

And besides, the versioning of kvm-kmod's are not obvious to me: I see 
these ones at sourceforge:

2.6.31.5
2.6.30
2.6.30.1
2.6.30-rc8
2.6.30-rc6

I don't undestand why they are numbered like the kernel, that's 
strange... More specifically, this is the question: If I have a kernel 
version N, what kvm-kmod can I compile in it? If I can just compile 
version N, then it's useless because that's identical to the kvm.ko I 
already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? 
That's a strange version numbering... why haven't you used the same 
numbering as for qemu-kvm?

> kvm-nn never was and never will be for production.  They always has been
> and always will be nothing more than development snapshots.
Ok I see. Thanks.

Thank you
Asdo

  reply	other threads:[~2009-11-10 14:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-08 18:42 Doubt on KVM-88 vulnerabilities Daniel Bareiro
2009-11-10 10:04 ` Avi Kivity
2009-11-10 11:10   ` Asdo
2009-11-10 12:03     ` Michael Tokarev
2009-11-10 14:19       ` Asdo [this message]
2009-11-10 14:42         ` Michael Tokarev
2009-11-10 15:05           ` Asdo
2009-11-10 16:25             ` Jan Kiszka
2009-12-14 11:08   ` Daniel Bareiro
2009-12-14 17:36     ` Daniel Bareiro
2009-12-14 18:39       ` Avi Kivity
2009-12-14 21:07         ` Daniel Bareiro
2009-12-15  1:56           ` Daniel Bareiro
2009-12-15 10:03           ` Avi Kivity
2009-12-14 18:38     ` Avi Kivity
2009-12-14 23:27       ` Daniel Bareiro

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=4AF97689.1070503@shiftmail.org \
    --to=asdo@shiftmail.org \
    --cc=kvm@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /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.