grsecurity forums

- qemu-kvm 0.12.4
- kernel 2.6.34.1
- grsecurity 2.2.0-2.6.34.1-201007101507
- gentoo hardened from anarchy overlay [1].
- amd64

qemu-kvm is very slow and produces 100% load on one core. I can even see the bios printing single characters. The problem first occured in an ebuild after 2.6.33. 2.6.33-r1 does not work anymore. [2] is the commit from 2.6.33 to 2.6.33-r1. The problem seems to be related to work done between 2.1.14-2.6.33-201003071645 (2.6.33) and 2.1.14-2.6.33.2-201004071936 (2.6.33-r1) or between kernel 2.6.33 and 2.6.33.2 (contained in 2.6.33-r1). The patches of gentoo have not changed between 2.6.33 and 2.6.33-r1.

[1] http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=tree;f=sys-kernel/hardened-sources;h=b355c2d5b4498ba992f66d7372662fbe83c224e0;hb=HEAD
[2] http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=commit;h=9e3c62080f1be0d1615694d9b79e1fb5e233b45a

I hope that helps to find the problem. I do not use UDEREF.

Sorry for the wrong board.

username wrote:The problem seems to be related to work done between 2.1.14-2.6.33-201003071645 (2.6.33) and 2.1.14-2.6.33.2-201004071936 (2.6.33-r1) or between kernel 2.6.33 and 2.6.33.2 (contained in 2.6.33-r1).

what changed in PaX in that timeframe was the introduction of UDEREF for amd64. did you perhaps enable it? if you did, try booting with pax_nouderef and see if it helps (in general, read its config help, it's not a 'free' feature on amd64, unfortunately).

PaX Team wrote:

username wrote:The problem seems to be related to work done between 2.1.14-2.6.33-201003071645 (2.6.33) and 2.1.14-2.6.33.2-201004071936 (2.6.33-r1) or between kernel 2.6.33 and 2.6.33.2 (contained in 2.6.33-r1).

what changed in PaX in that timeframe was the introduction of UDEREF for amd64. did you perhaps enable it? if you did, try booting with pax_nouderef and see if it helps (in general, read its config help, it's not a 'free' feature on amd64, unfortunately).

Haven't tried it yet but in the help screen it says if you have hardware assisted virtualization there shouldn't be a slowdown.

konst wrote:Haven't tried it yet but in the help screen it says if you have hardware assisted virtualization there shouldn't be a slowdown.

the help wasn't updated for the amd64 version since it's kinda experimental still, better read the announcement email on the list about what to expect .

As I said before, I do not use UDEREF at all. It is disabled in the kernel configuration. I tried to boot with the kernel parameter, but it did not solve the problem. I don't understand, that nobody else has the same problem. I do not configure PaX or grsec myself. I use the predefined profiles from hardened gentoo. Is there anything else, I need to disable in the kernel configuration?

username wrote:As I said before, I do not use UDEREF at all.

oh sorry, i missed it, must be the heat .

Is there anything else, I need to disable in the kernel configuration?

yes, do you have KERNEXEC enabled? it enables the common infrastructure used by UDEREF as well and can cause the slowdown.

oh, i've been searching for the same issue and came across boardreader.com/thread/Hardened_kernel_2_6_38_and_latest_qemu_k_1mboX210.html. Thanks you too, for providing some hints in order to solve the slow speed of qemu+kvm!

as of yesterday, this problem should be fixed finally.