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