Doubt on KVM-88 vulnerabilities

Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]


Hi all!

I'm using KVM-88 compiled by myself from the source code provided by the
official site of the project.

Is this version of KVM vulnerable to the mentioned thing in the
DSA-1907-1 [1]? In such case, there is some published patch that can be
applied or some new version that solves this?

Thanks in advance for your reply.

Regards,
Daniel

[1] http://lists.debian.org/debian-security-announce/2009/msg00229.html
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Squeeze - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Avi Kivity]

On 11/08/2009 08:42 PM, Daniel Bareiro wrote:
> Hi all!
>
> I'm using KVM-88 compiled by myself from the source code provided by the
> official site of the project.
>
> Is this version of KVM vulnerable to the mentioned thing in the
> DSA-1907-1 [1]?

Yes.

> In such case, there is some published patch that can be
> applied or some new version that solves this?
>    

I recommend to use distro-provided modules (or kernel.org kernels within 
their support period) for production use.  This ensures you get security 
and stability fixes.  kvm-89 will fix these issues, but as it's a 
development snapshot, may introduce new issues.

-- 
error compiling committee.c: too many arguments to function

Re: Doubt on KVM-88 vulnerabilities

[Asdo]

Avi Kivity wrote:
> I recommend to use distro-provided modules (or kernel.org kernels 
> within their support period) for production use.  This ensures you get 
> security and stability fixes.  kvm-89 will fix these issues, but as 
> it's a development snapshot, may introduce new issues.

This is interesting.

I prefer compiling from source especially for upgrading KVM on 
production systems, because then I do not need to upgrade the kernel 
(may introduce new stability issues on very new kernels) or the distro 
(may introduce LOTS of new changes and stability issues on production 
sytems). KVM is newer and evolves more rapidly than the kernel so it is 
more beneficial to upgrade KVM than the rest of the kernel or distro

However for compiling from source I would need to know which versions of 
KVM are "stable" and which are not.

I see the 89 you tell about, is not released yet:
http://sourceforge.net/projects/kvm/files/
So did you mean that 89 is not "yet" for production use or will "never" 
be for production use?

Are there versions number which are "stabilization" versions and others 
which are development, or they are all equal?

You know it would be great if the KVM versions would be versioned like 
the kernels, so that we could have kvm version 86.1, 86.2, 86.3 which 
would apply only the bug fixes and not new stuff which might be risky 
(i.e. no speed optimizations) so one willing to upgrade a production 
system could choose a somewhat older version with a higher bugfix 
version number.

In the past I chose the kvm-86 which had been just released (i.e. 
visible in http://sourceforge.net/projects/kvm/files/ ) but there was a 
bug on the CPU detection causing the message "This kernel requires an 
x86-64 CPU, but only detected an i686 CPU. \n Unable to boot - please 
use a kernel appropriate for your CPU.". I had to manually find and 
apply the patch 
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=8fa3b3ce6e 
. Luckily this bug was discussed somewhere so I could find the patch.

Summing up, it would be great to have some maintained kvm versions...

BTW I do not know what are kvm-kmod's or qemu-kvm's downloadable from 
http://sourceforge.net/projects/kvm/files/ : I always compile the "kvm" 
from source.  Are those the solution to my problem? Where can I find 
info about the difference between the three?

Thank you

Re: Doubt on KVM-88 vulnerabilities

[Michael Tokarev]

Asdo wrote:
> Avi Kivity wrote:
>> I recommend to use distro-provided modules (or kernel.org kernels 
>> within their support period) for production use.  This ensures you get 
>> security and stability fixes.  kvm-89 will fix these issues, but as 
>> it's a development snapshot, may introduce new issues.
> 
> This is interesting.
> 
> I prefer compiling from source especially for upgrading KVM on 
> production systems, because then I do not need to upgrade the kernel 
> (may introduce new stability issues on very new kernels) or the distro 
> (may introduce LOTS of new changes and stability issues on production 
> sytems). KVM is newer and evolves more rapidly than the kernel so it is 
> more beneficial to upgrade KVM than the rest of the kernel or distro

There's no need to compile kvm _modules_ if you're using recent-enough
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.

> 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.

> I see the 89 you tell about, is not released yet:
> http://sourceforge.net/projects/kvm/files/
> So did you mean that 89 is not "yet" for production use or will "never" 
> be for production use?

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

And the whole thing has been asked and answered numerous times here
and elsewhere.

/mjt

Re: Doubt on KVM-88 vulnerabilities

[Asdo]

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

Re: Doubt on KVM-88 vulnerabilities

[Michael Tokarev]

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

Well, today wasn't my best day.
You're right the documentation on the matter is nearly non-existing.

[]
> 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 

In kvm it's the opposite.  Kernel part is very small and the interface
does not change as frequently.  It's basically just a wrapper around
the CPU VT extensions.

[]
> But what about stable kernel modules?
> 
> Are these the kvm-kmod's?

Yes.

> 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?

Because such numbering proved to be confusing, and you are confused by
it too.  The above numbers means just like, kvm-kmod from kernel 2.6.30.1
(say), but "ported" to a wider range of kernels.  kvm-kmod is being
developed as part of kernel.


Btw, 2.6.24 and in fact anything before ~2.6.28 might be problematic for
real kvm usage, due to other parts of the kernel.  Applies to both
host and guest kernels.

/mjt

Re: Doubt on KVM-88 vulnerabilities

[Asdo]

Great, thanks for your reply!

All clear, except one thing, pls see --->

Michael Tokarev wrote:
>>
>> 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?
> And besides, the versioning of kvm-kmod's are not obvious to me: I see 
> these ones at sourceforge:
>
> Because such numbering proved to be confusing, and you are confused by
> it too.  The above numbers means just like, kvm-kmod from kernel 2.6.30.1
> (say), but "ported" to a wider range of kernels.  kvm-kmod is being
> developed as part of kernel.
Ok so you mean I can indeed take kvm-kmod 2.6.31.5 and compile it 
against my older host kernel?
(except that the host kernel needs to be anyway >= 2.6.28 as you say below)
Did I understand correctly?

> Btw, 2.6.24 and in fact anything before ~2.6.28 might be problematic for
> real kvm usage, due to other parts of the kernel.  Applies to both
> host and guest kernels.

Thank you
Asdo

Re: Doubt on KVM-88 vulnerabilities

[Jan Kiszka]

Asdo wrote:
> Great, thanks for your reply!
> 
> All clear, except one thing, pls see --->
> 
> Michael Tokarev wrote:
>>>
>>> 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?
>> And besides, the versioning of kvm-kmod's are not obvious to me: I see
>> these ones at sourceforge:
>>
>> Because such numbering proved to be confusing, and you are confused by
>> it too.  The above numbers means just like, kvm-kmod from kernel 2.6.30.1
>> (say), but "ported" to a wider range of kernels.  kvm-kmod is being
>> developed as part of kernel.
> Ok so you mean I can indeed take kvm-kmod 2.6.31.5 and compile it
> against my older host kernel?
> (except that the host kernel needs to be anyway >= 2.6.28 as you say below)
> Did I understand correctly?
> 

Please see http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/42256

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Hi, Avi.

On Tuesday, 10 November 2009 12:04:40 +0200,
Avi Kivity wrote:

>> I'm using KVM-88 compiled by myself from the source code provided by the
>> official site of the project.
>>
>> Is this version of KVM vulnerable to the mentioned thing in the
>> DSA-1907-1 [1]?

> Yes.

>> In such case, there is some published patch that can be
>> applied or some new version that solves this?

> I recommend to use distro-provided modules (or kernel.org kernels within  
> their support period) for production use.  This ensures you get security  
> and stability fixes.  kvm-89 will fix these issues, but as it's a  
> development snapshot, may introduce new issues.

Minutes ago I've downloaded of kernel.org the source code of Linux 2.6.32
because I wanted to test with KSM, that it seems to me a very
interesting aggregate. As you said above, surely the modules of
2.6.32 are going to be newer than the compiled ones with KVM-88 with
security fixes like the one of the DSA-1907-1.

Then, I imagine that only it would be necessary to compile the
userspace. The steps that I habitually followed are the mentioned ones
in the section 'Unpacking and configuring kvm components' of this [1]
document, but I suppose that to only compile userspace it will be
necessary to follow a different procedure. Is there some document that
you can indicate to me where are mentioned these steps?

Very interesting the replies in this thread. It drew attention 
powerfully to me which Michael Tokarev said that KVM never was and 
never will be for production. Personally I'm using KVM-88 with 2.6.30 
and it works wonderfully well.

Thanks for your reply.

Regards,
Daniel

[1] http://www.linux-kvm.org/page/HOWTO1
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Squeeze - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

On Monday, 14 December 2009 08:08:32 -0300,
Daniel Bareiro wrote:

> > I recommend to use distro-provided modules (or kernel.org kernels
> > within  their support period) for production use. This ensures you
> > get security  and stability fixes.  kvm-89 will fix these issues,
> > but as it's a  development snapshot, may introduce new issues.

> Minutes ago I've downloaded of kernel.org the source code of Linux
> 2.6.32 because I wanted to test with KSM, that it seems to me a very
> interesting aggregate. As you said above, surely the modules of 2.6.32
> are going to be newer than the compiled ones with KVM-88 with security
> fixes like the one of the DSA-1907-1.
> 
> Then, I imagine that only it would be necessary to compile the
> userspace. The steps that I habitually followed are the mentioned ones
> in the section 'Unpacking and configuring kvm components' of this [1]
> document, but I suppose that to only compile userspace it will be
> necessary to follow a different procedure. Is there some document that
> you can indicate to me where are mentioned these steps?

According to I found looking for in Internet, qemu-kvm does not include
the kernel modules but only the userspace and it is considered to be
stable. I've downloaded qemu-kvm-0.11.0 and I build it with 'make' and
'make install' like did with kvm-nn but it seems that KSM is not
working:

root@ubuntu:~# uname -a
Linux ubuntu 2.6.32-dgb #1 SMP Mon Dec 14 06:18:06 ART 2009 x86_64 GNU/Linux

root@ubuntu:~# cat /sys/kernel/mm/ksm/max_kernel_pages
253738

root@ubuntu:~# cat /sys/kernel/mm/ksm/run
1

root@ubuntu:~# cat /sys/kernel/mm/ksm/pages_sharing
0

root@ubuntu:~# cat /sys/kernel/mm/ksm/pages_shared
0

Is it possible that there is to apply a patch on some of the files of
qemu-kvm-0.11.0? At least a fast search in the files does not show some
definition of MADV_MERGEABLE.

Also I have understood that it must exist support of KSM on glibc. I'm
using ubuntu Hardy Heron. Is it possible that this support is not
enabled?

Regards,
Daniel
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Squeeze - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Avi Kivity]

On 12/14/2009 01:08 PM, Daniel Bareiro wrote:
>
> Then, I imagine that only it would be necessary to compile the
> userspace.

It is not necessary to rebuild userspace, unless you want to use new 
features.

> The steps that I habitually followed are the mentioned ones
> in the section 'Unpacking and configuring kvm components' of this [1]
> document, but I suppose that to only compile userspace it will be
> necessary to follow a different procedure. Is there some document that
> you can indicate to me where are mentioned these steps?
>    

I suggest downloading qemu-kvm-0.12.0-rc2.  All you need is a 
./configure; make; make install.

> Very interesting the replies in this thread. It drew attention
> powerfully to me which Michael Tokarev said that KVM never was and
> never will be for production. Personally I'm using KVM-88 with 2.6.30
> and it works wonderfully well.
>    

I doubt he meant kvm is not for production use.  Instead, the 
development snapshots are not meant for production use (as they do not 
receive updates, for example).  Instead, use the modules and userspace 
provided by your distribution, or the kvm-kmod and qemu-kvm packages.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: Doubt on KVM-88 vulnerabilities

[Avi Kivity]

On 12/14/2009 07:36 PM, Daniel Bareiro wrote:
>
> According to I found looking for in Internet, qemu-kvm does not include
> the kernel modules but only the userspace and it is considered to be
> stable. I've downloaded qemu-kvm-0.11.0 and I build it with 'make' and
> 'make install' like did with kvm-nn but it seems that KSM is not
> working:
>
>    

The qemu-kvm-0.11 series does not support ksm.  Try the 0.12 series.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

Hi, Avi.

On Monday, 14 December 2009 20:39:13 +0200,
Avi Kivity wrote:

>> According to I found looking for in Internet, qemu-kvm does not
>> include the kernel modules but only the userspace and it is
>> considered to be stable. I've downloaded qemu-kvm-0.11.0 and I build
>> it with 'make' and 'make install' like did with kvm-nn but it seems
>> that KSM is not working:

> The qemu-kvm-0.11 series does not support ksm.  Try the 0.12 series.

Ah! I see you upload it today :-)

After a ./configure, I'm obtaining the following error when doing make:


root@ubuntu:~/qemu-kvm-0.12.0-rc2# make
  GEN   config-host.h
  CC    qemu-nbd.o
  CC    qemu-tool.o
  CC    cutils.o
  CC    cache-utils.o
  CC    qemu-malloc.o
  CC    qemu-option.o
  CC    module.o
  CC    nbd.o
  CC    block.o
  CC    aio.o
  CC    aes.o
  CC    osdep.o
  CC    posix-aio-compat.o
  CC    compatfd.o
compatfd.c: In function ‘qemu_eventfd’:
compatfd.c:137: error: ‘ret’ undeclared (first use in this function)
compatfd.c:137: error: (Each undeclared identifier is reported only once
compatfd.c:137: error: for each function it appears in.)
make: *** [compatfd.o] Error 1


Thanks for your reply.

Regards,
Daniel
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Squeeze - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

Hi, Avi.

On Monday, 14 December 2009 20:38:08 +0200,
Avi Kivity wrote:

>> Then, I imagine that only it would be necessary to compile the
>> userspace.

> It is not necessary to rebuild userspace, unless you want to use new
> features.

Good. Then if we did not need new features and we only want to apply
security fixes, installing kvm-kmod would be sufficient?

Backing, for example, to the DSA-1907-1 [1] with KVM-88 and Linux
2.6.30.4 from kernel.org, under this situation what version of kvm-kmod
would have to build? I remember that when I did the compilation at that
time I had to apply the patch mentioned in this [2] thread. This no
longer would be necessary?

The dependencies for kvm-kmod are the same that for kvm-nn?

I guess that during the building of the new modules, the virtual
machines would have to be down. Is this correct?

>> The steps that I habitually followed are the mentioned ones in the
>> section 'Unpacking and configuring kvm components' of this [1]
>> document, but I suppose that to only compile userspace it will be
>> necessary to follow a different procedure. Is there some document
>> that you can indicate to me where are mentioned these steps?

> I suggest downloading qemu-kvm-0.12.0-rc2.  All you need is a
> ./configure; make; make install.

I forgot to mention 'configure' in the other mail, although also I had
used it. Thanks to indicate the procedure to me. With the packages
mentioned in the dependencies for kvm-nn [3], it seems that it was
sufficient, although perhaps now it is not necessary to install all.

Now I'm having the problem that told you when I doing 'make'.

>> Very interesting the replies in this thread. It drew attention
>> powerfully to me which Michael Tokarev said that KVM never was and
>> never will be for production. Personally I'm using KVM-88 with 2.6.30
>> and it works wonderfully well.

> I doubt he meant kvm is not for production use.

It can be, or perhaps he didn't have a good day, as he said :-D

> Instead, the development snapshots are not meant for production use
> (as they do not receive updates, for example).  Instead, use the
> modules and userspace provided by your distribution, or the kvm-kmod
> and qemu-kvm packages.

Thanks for the explanation.

Thanks for your reply.

Regards,
Daniel

[1] http://lists.debian.org/debian-security-announce/2009/msg00229.html
[2] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/36981/focus=36985
[3] http://www.linux-kvm.org/page/HOWTO1
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

Hi, Avi and Chris.

On Monday, 14 December 2009 18:07:57 -0300,
Daniel Bareiro wrote:

> >> According to I found looking for in Internet, qemu-kvm does not
> >> include the kernel modules but only the userspace and it is
> >> considered to be stable. I've downloaded qemu-kvm-0.11.0 and I
> >> build it with 'make' and 'make install' like did with kvm-nn but it
> >> seems that KSM is not working:
 
> > The qemu-kvm-0.11 series does not support ksm.  Try the 0.12 series.
 
> Ah! I see you upload it today :-)
> 
> After a ./configure, I'm obtaining the following error when doing make:
> 
> 
> root@ubuntu:~/qemu-kvm-0.12.0-rc2# make
>   GEN   config-host.h
>   CC    qemu-nbd.o
>   CC    qemu-tool.o
>   CC    cutils.o
>   CC    cache-utils.o
>   CC    qemu-malloc.o
>   CC    qemu-option.o
>   CC    module.o
>   CC    nbd.o
>   CC    block.o
>   CC    aio.o
>   CC    aes.o
>   CC    osdep.o
>   CC    posix-aio-compat.o
>   CC    compatfd.o
> compatfd.c: In function ‘qemu_eventfd’:
> compatfd.c:137: error: ‘ret’ undeclared (first use in this function)
> compatfd.c:137: error: (Each undeclared identifier is reported only once
> compatfd.c:137: error: for each function it appears in.)
> make: *** [compatfd.o] Error 1

I confirm that applying the patch sent by Chris Wright, no longer I have
this problem. Thanks, Chris! Even so, KSM seems not to be working:

root@ubuntu:~# cat /sys/kernel/mm/ksm/max_kernel_pages
253738

root@ubuntu:~# cat /sys/kernel/mm/ksm/run
1

root@ubuntu:~# cat /sys/kernel/mm/ksm/pages_sharing
0

root@ubuntu:~# cat /sys/kernel/mm/ksm/pages_shared
0

Is it possible that, as I've mentioned in another message of this
thread, the version of glibc of Ubuntu Hardy Heron doesn't have support
for KSM?

Regards,
Daniel
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Doubt on KVM-88 vulnerabilities

[Avi Kivity]

On 12/14/2009 11:07 PM, Daniel Bareiro wrote:
> Ah! I see you upload it today :-)
> After a ./configure, I'm obtaining the following error when doing make:
>
>
> root@ubuntu:~/qemu-kvm-0.12.0-rc2# make
>    GEN   config-host.h
>    CC    qemu-nbd.o
>    CC    qemu-tool.o
>    CC    cutils.o
>    CC    cache-utils.o
>    CC    qemu-malloc.o
>    CC    qemu-option.o
>    CC    module.o
>    CC    nbd.o
>    CC    block.o
>    CC    aio.o
>    CC    aes.o
>    CC    osdep.o
>    CC    posix-aio-compat.o
>    CC    compatfd.o
> compatfd.c: In function ‘qemu_eventfd’:
> compatfd.c:137: error: ‘ret’ undeclared (first use in this function)
> compatfd.c:137: error: (Each undeclared identifier is reported only once
> compatfd.c:137: error: for each function it appears in.)
> make: *** [compatfd.o] Error 1
>
>
>    

Christ Wright just sent a fix for this, we'll have a fixed version shortly.

http://patchwork.kernel.org/patch/67432/

-- 
error compiling committee.c: too many arguments to function