Created attachment 426292 [details] 4.3.3-config I switched to 3.14.51-hardened to 4.1.7-hardened-r1 / 4.3.3-hardened-r4. I noticed that the system is a bit slow, so I just did a simple benchmark with an emerge. Emerging cpio with 3.14.51 I have: real 1m26.211s Emerging cpio with 4.1.7-hardened-r1 I have: real 5m18.237s Emerging cpio with 4.3.3-hardened-r4 I have: real 5m20.665s I tried to change the from security to performance in the grsecurity preferences but nothing has changed. If I complete disable grsecurity from the 4.3.3 I have the same performance I had with 3.14.51 This problem seems to happen only in a kvm guest. I'm attaching the conf which reproduces the problem and I'm available for further tests.
Portage 2.2.26 (python 2.7.10-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.21-r2, 4.3.3-hardened-r4 x86_64) ================================================================= System uname: Linux-4.3.3-hardened-r4-x86_64-QEMU_Virtual_CPU_version_2.4.0-with-gentoo-2.2 KiB Mem: 4042208 total, 3784512 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Tue, 23 Feb 2016 07:00:01 +0000 sh bash 4.3_p42-r1 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p42-r1::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10-r1::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.19.1::gentoo sys-apps/sandbox: 2.10-r1::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://192.168.0.22/gentoo-portage priority: -1000 Installed sets: @arkham, @fileserver, @maven, @oe-web, @scheduler, @sitovetrina-e2y, @underworld ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=x86-64" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/maven-bin-3.1/conf" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=x86-64" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y -b" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://192.168.0.22/ http://distfiles.gentoo.org http://gentoo.wheel.sk/ http://mirror.netcologne.de/gentoo/ http://mirrors.linuxant.fr/distfiles.gentoo.org/" LANG="it_IT.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp/" USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx dri gdbm hardened iconv justify mmx mmxext modules multilib ncurses nptl openmp pam pax_kernel pcre pie readline seccomp session sse sse2 ssl ssp symlink tcpd unicode urandom xattr xtpax zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" NGINX_MODULES_HTTP="access fastcgi gzip proxy rewrite" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" USE_PYTHON="2.7"
(In reply to Agostino Sarubbo from comment #0) > > I tried to change the from security to performance in the grsecurity > preferences but nothing has changed. > > If I complete disable grsecurity from the 4.3.3 I have the same performance > I had with 3.14.51 > > > This problem seems to happen only in a kvm guest. > I'm attaching the conf which reproduces the problem and I'm available for > further tests. Have you compared hardened-sources and vanilla.
(In reply to Anthony Basile from comment #2) > Have you compared hardened-sources and vanilla. Not really, but as I said, if I disable grsecurity from 4.3.3 the performance comes back.
From the tests I was able to do, if I disable CONFIG_PAX_MEMORY_UDEREF on 4.3.3 it works as expected. Can you reproduce this problem with the latest qemu in the tree? Should UDEREF be disabled if the autoconfig select: -type GUEST -virtualization KVM ?
(In reply to Agostino Sarubbo from comment #4) > From the tests I was able to do, if I disable CONFIG_PAX_MEMORY_UDEREF on > 4.3.3 it works as expected. > > > Can you reproduce this problem with the latest qemu in the tree? > > > Should UDEREF be disabled if the autoconfig select: > -type GUEST > -virtualization KVM > > ? okay that's helpful. let me test with the latest grsec patches and let upstream know. they may want to change kconfig so that UDEREF is off when virt guest performance is chosen.
(In reply to Anthony Basile from comment #5) > (In reply to Agostino Sarubbo from comment #4) > > Should UDEREF be disabled if the autoconfig select: > > -type GUEST > > -virtualization KVM it also depends on the perf vs. security selection and VIRT_EPT. > okay that's helpful. let me test with the latest grsec patches and let > upstream know. they may want to change kconfig so that UDEREF is off when > virt guest performance is chosen. his config has this: CONFIG_GRKERNSEC_CONFIG_VIRT_EPT=y # CONFIG_GRKERNSEC_CONFIG_PRIORITY_PERF is not set CONFIG_GRKERNSEC_CONFIG_PRIORITY_SECURITY=y and our Kconfig has this: config PAX_MEMORY_UDEREF + bool "Prevent invalid userland pointer dereference" + default y if GRKERNSEC_CONFIG_AUTO && !(X86_64 && GRKERNSEC_CONFIG_PRIORITY_PERF) && !(X86_64 && GRKERNSEC_CONFIG_VIRT_HOST && GRKERNSEC_CONFIG_VIRT_VIRTUALBOX) && (!X86 || GRKERNSEC_CONFIG_VIRT_NONE || GRKERNSEC_CONFIG_VIRT_EPT) that is, choosing VIRT_EPT will enable UDEREF even for a performance oriented config (as documented by the config help). i wonder, what is the host cpu? can you post /proc/cpuinfo from both the host and the guest?
Created attachment 426378 [details] cpuinfo In any case this bug sounds strange to me because I have the same setup on a first generation hw and uderef does not cause any problems
Created attachment 426380 [details] cpuinfo wrong copy-paste
(In reply to Agostino Sarubbo from comment #7) > Created attachment 426378 [details] > cpuinfo > > In any case this bug sounds strange to me because I have the same setup on a > first generation hw and uderef does not cause any problems which UDEREF gets selected on the older host/guest? this new system is haswell+ and has both PCID and INVPCID support on the host however they're not getting passed down to the guest which in turn will activate the slow UDEREF logic. what cpu model does your qemu emulate? my guess is that you're not using "-cpu host" and thus lose those two important features that are needed for a better performing UDEREF.
(In reply to PaX Team from comment #9) > which UDEREF gets selected on the older host/guest? From a better check, uderef was not enabled on the old system/guest. > this new system is > haswell+ and has both PCID and INVPCID support on the host however they're > not getting passed down to the guest which in turn will activate the slow > UDEREF logic. what cpu model does your qemu emulate? my guess is that you're > not using "-cpu host" and thus lose those two important features that are > needed for a better performing UDEREF. Usually I'm using (via libvirt/virt-install) --cpu model=none. Now I give a chance to "--cpu host" and the guest seems to have pcid/invpcid/pciduderef. I re-tried the benchmark and I'm able to complete the task in: real 2m18.587s With no uderef the result is: real 1m26.211s So I lose ~ 60% of the performance. Is for you normal/acceptable of there is still something wrong?
(In reply to Agostino Sarubbo from comment #10) > (In reply to PaX Team from comment #9) > > which UDEREF gets selected on the older host/guest? > From a better check, uderef was not enabled on the old system/guest. > > > > this new system is > > haswell+ and has both PCID and INVPCID support on the host however they're > > not getting passed down to the guest which in turn will activate the slow > > UDEREF logic. what cpu model does your qemu emulate? my guess is that you're > > not using "-cpu host" and thus lose those two important features that are > > needed for a better performing UDEREF. > > Usually I'm using (via libvirt/virt-install) --cpu model=none. Now I give a > chance to "--cpu host" and the guest seems to have pcid/invpcid/pciduderef. > > I re-tried the benchmark and I'm able to complete the task in: > real 2m18.587s > > With no uderef the result is: > real 1m26.211s > > > So I lose ~ 60% of the performance. Is for you normal/acceptable of there is > still something wrong? It's worth checking if you are using the strong UDEREF on both sides, just run: dmesg | grep UDEREF And tell me if you get a line like: PAX: strong UDEREF enabled On both host and guest.
(In reply to Francisco Blas Izquierdo Riera from comment #11) > It's worth checking if you are using the strong UDEREF on both sides, just > run: > dmesg | grep UDEREF > > And tell me if you get a line like: > PAX: strong UDEREF enabled > > On both host and guest. HOST: Configuration Method (Automatic) ---> Usage Type (Server) ---> Virtualization Type (Host) ---> Virtualization Hardware (EPT/RVI Processor Support) ---> Virtualization Software (KVM) ---> Required Priorities (Performance) ---> No output from dmesg|grep UDEREF. The module is not enabled and is not enabled even if I change Performance To security GUEST: Configuration Method (Automatic) ---> Usage Type (Server) ---> Virtualization Type (Guest) ---> Virtualization Hardware (EPT/RVI Processor Support) ---> Virtualization Software (KVM) ---> Required Priorities (Security) ---> PAX: strong UDEREF enabled If I change from security to performance, the module is still enabled and dmesg returns the same output. Is fine that the HOST has not UDEREF enabled by the autoconf if is an EPT/RVI ?
(In reply to Agostino Sarubbo from comment #12) > Is fine that the HOST has not UDEREF enabled by the autoconf if is an > EPT/RVI ? it depends on what else is in your host config. if you search for UDEREF in menuconfig, you'll see the exact dependencies and their current values. as for UDEREF's performance impact, i'm afraid it's as good (or bad) as it gets now that you enabled PCID/etc.
