# PaX usage on a non-hardened system?

## D-LINC

I was reading a little bit about PaX and it seemed like a sensible thing to do for security reasons. Does my Gentoo system already use PaX in some way? I see pax-utils is already installed on my system (though not in my world file) and I seem to remember some messages about PaX marking binaries near the end of merges that I have done.

----------

## cach0rr0

PaX has not been accepted into the mainline kernel by upstream, nor are their plans to do so AFAIK

so it will always require separate patching, and thusly hardened-sources on gentoo. It is not a small patch either

people can and do run hardened-* on the desktop, but there are special considerations

----------

## Veldrin

portage uses pax-utils to modify binaries, that the run on a hardened (PaX enabled) system.

----------

## nlsa8z6zoz7lyih3ap

I used to run "hardened"  with grsecurity  + pax on my desktop and was very happy for a long while. Then something about Grsecurity + Pax changed and I no longer do. The deal breaker for me was this: Even with Grsecurity and Pax totally disabled  in kernel's patched with them, the kernel compiled broke my vmware-server which I then used. (I now use vmware-player, but would expect the same results.)  It turned out, the grsecurity people told me, that their patches change the kernel even if one disables all of the features.  (see https://forums.gentoo.org/viewtopic-p-5154743-highlight-.html#5154743 for more details.)  Prior to that I could use vmware with Pax and grsecurity merely  by setting 

```
 CONFIG_PAX_KERNEXEC=n
```

  After this I could not. Too bad. I really liked grsecurity+pax, but I did have to be able to use my Desktop with vmware.

Note:  I still I still use "-fstack-protector"  in my CFLAGS  and enable the corresponding part in the kernel. I assume that this gives some protection.

----------

## Hu

It is true that PaX hardening breaks some of the proprietary modules.

OP: given the ease with which one can switch between hardened and regular kernels of the same base revision, I encourage you to try hardened, especially if your kernel is not tainted.  At worst, the machine will panic and require a switch back to a non-hardened kernel.

----------

## D-LINC

Quick question regarding grsecurity: grsecurity only tightens restrictions on a system, correct? It never increases access to any resource beyond what is allowed by normal Linux permissions, correct? For example, even if I were to completely screw up my grsecurity policy configuration, there is no way the system would be any less secure than it was before I started using grsecurity, right? Just want to be crystal clear on that point.

----------

## cach0rr0

 *D-LINC wrote:*   

> Quick question regarding grsecurity: grsecurity only tightens restrictions on a system, correct? It never increases access to any resource beyond what is allowed by normal Linux permissions, correct? For example, even if I were to completely screw up my grsecurity policy configuration, there is no way the system would be any less secure than it was before I started using grsecurity, right? Just want to be crystal clear on that point.

 

I can't envision a way you could configure RBAC under grsec that you'd nullify filesystem permissions to the extent that something that should be blocked becomes allowed. 

Having said all that, there's nothing that says you have to set up RBAC under grsec. I have a number of systems where I don't. On an uber important server, sure, but not so critical on a desktop/laptop

----------

## D-LINC

 *cach0rr0 wrote:*   

>  *D-LINC wrote:*   Quick question regarding grsecurity: grsecurity only tightens restrictions on a system, correct? It never increases access to any resource beyond what is allowed by normal Linux permissions, correct? For example, even if I were to completely screw up my grsecurity policy configuration, there is no way the system would be any less secure than it was before I started using grsecurity, right? Just want to be crystal clear on that point. 
> 
> I can't envision a way you could configure RBAC under grsec that you'd nullify filesystem permissions to the extent that something that should be blocked becomes allowed. 
> 
> Having said all that, there's nothing that says you have to set up RBAC under grsec. I have a number of systems where I don't. On an uber important server, sure, but not so critical on a desktop/laptop

 

I was actually thinking of giving RBAC a try (for my Web server). So, your saying that it is possible somehow to "nullify" filesystem permissions? What do you mean by that?

----------

## cach0rr0

 *D-LINC wrote:*   

>  So, your saying that it is possible somehow to "nullify" filesystem permissions? 

 

i was saying the opposite actually; you can restrict above and beyond, but i dont think youll make things *more* permissive than your filesystem permissions with RBAC

----------

## nlsa8z6zoz7lyih3ap

 *Quote:*   

> OP: given the ease with which one can switch between hardened and regular kernels of the same base revision, I encourage you to try hardened, especially if your kernel is not tainted. At worst, the machine will panic and require a switch back to a non-hardened kernel.

 

I largely agree. However a certain amount of caution is occasionally  required:

The hardened kernel crashed my vmware virtual machine in such a destructive fashion that

it would not boot again, even with the gentoo-sources kernel. However I keep frequent backups

(i.e. copies of my virtual machine) so it was the easiest thing to replace the damaged machine with the copy. 

More generally, as I like to "experiment" ("play?") with my gentoo installation, I keep frequent backups of it as well. I strongly recommend this practice.

----------

## Hu

 *nlsa8z6zoz7lyih3ap wrote:*   

> I largely agree. However a certain amount of caution is occasionally  required:
> 
> The hardened kernel crashed my vmware virtual machine in such a destructive fashion that
> 
> it would not boot again, even with the gentoo-sources kernel.

 Could you elaborate on the nature of the failure to boot?  Specifically, was the vmdk intact and the guest filesystem trashed or was the vmdk itself broken?  If the former, you would be able to boot a guest from a LiveCD, but likely not be able to access some or all of the guest filesystems.  If the latter, VMware would likely refuse to open that guest at all.

----------

## D-LINC

Could you guys help me with a little troubleshooting? I installed a hardened kernel, as well as the paxctl and pax-util packages. (Haven't installed gradm yet.) After reboot, my Web server won't start (lighttpd). This seems to be the issue:

```
aquinas ~ # grep FATAL /var/log/messages

Dec 21 21:21:17 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 21:21:22 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 21:21:22 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 21:21:22 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 21:21:23 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 21:21:23 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

Dec 21 23:59:58 aquinas modprobe: FATAL: Error inserting ipv6 (/lib/modules/3.0.4-hardened-r5/kernel/net/ipv6/ipv6.ko): Cannot allocate memory

aquinas ~ # grep vmap /var/log/messages

Dec 21 21:21:17 aquinas kernel: vmap allocation for size 249856 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:17 aquinas kernel: vmap allocation for size 225280 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:17 aquinas kernel: vmap allocation for size 225280 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:17 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:22 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:22 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:22 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:23 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 21:21:23 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

Dec 21 23:59:58 aquinas kernel: vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

aquinas ~ # dmesg | grep failed

 pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d

kretprobe: lookup failed: __switch_to

scsi: <fdomain> Detection failed (no card)

vmap allocation for size 249856 failed: use vmalloc=<size> to increase size.

vmap allocation for size 225280 failed: use vmalloc=<size> to increase size.

vmap allocation for size 225280 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.

vmap allocation for size 233472 failed: use vmalloc=<size> to increase size.
```

Could someone explain this issue to me? (Err, what is vmalloc for again...?)

Here's some sys info:

```
# emerge --info

Portage 2.1.10.11 (default/linux/x86/10.0, gcc-4.5.3, glibc-2.13-r4, 3.0.4-hardened-r5 i686)

=================================================================

System uname: Linux-3.0.4-hardened-r5-i686-Intel-R-_Atom-TM-_CPU_N270_@_1.60GHz-with-gentoo-2.0.3

Timestamp of tree: Thu, 15 Dec 2011 23:30:01 +0000

app-shells/bash:          4.1_p9

dev-lang/python:          2.6.6-r2, 2.7.2-r3, 3.1.4-r3

dev-util/cmake:           2.8.4-r1

dev-util/pkgconfig:       0.26

sys-apps/baselayout:      2.0.3

sys-apps/openrc:          0.9.4

sys-apps/sandbox:         2.5

sys-devel/autoconf:       2.68

sys-devel/automake:       1.11.1

sys-devel/binutils:       2.21.1-r1

sys-devel/gcc:            4.5.3-r1

sys-devel/gcc-config:     1.4.1-r1

sys-devel/libtool:        2.4-r1

sys-devel/make:           3.82-r1

sys-kernel/linux-headers: 2.6.39 (virtual/os-headers)

sys-libs/glibc:           2.13-r4

Repositories: gentoo gentoo-haskell

ACCEPT_KEYWORDS="x86"

ACCEPT_LICENSE="* -@EULA"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=i686 -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-O2 -march=i686 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"

FFLAGS=""

GENTOO_MIRRORS="http://distfiles.gentoo.org"

LANG="en_US.UTF-8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/var/lib/layman/haskell"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="acl berkdb bindist bzip2 caps cli cracklib crypt cups cxx dri emacs fortran gdbm gnutls gpm iconv ipv6 modules mudflap ncurses nls nptl nptlonly openmp pam pcre pppd readline session ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

# cat /proc/meminfo 

MemTotal:        1014828 kB

MemFree:          625684 kB

Buffers:             656 kB

Cached:            69128 kB

SwapCached:            0 kB

Active:            56284 kB

Inactive:          45336 kB

Active(anon):      31888 kB

Inactive(anon):      504 kB

Active(file):      24396 kB

Inactive(file):    44832 kB

Unevictable:           0 kB

Mlocked:               0 kB

HighTotal:        125768 kB

HighFree:          20348 kB

LowTotal:         889060 kB

LowFree:          605336 kB

SwapTotal:             0 kB

SwapFree:              0 kB

Dirty:                 0 kB

Writeback:             0 kB

AnonPages:         31920 kB

Mapped:             9884 kB

Shmem:               556 kB

Slab:             143736 kB

SReclaimable:     125332 kB

SUnreclaim:        18404 kB

KernelStack:         632 kB

PageTables:          652 kB

NFS_Unstable:          0 kB

Bounce:                0 kB

WritebackTmp:          0 kB

CommitLimit:      507412 kB

Committed_AS:     150332 kB

VmallocTotal:     122880 kB

VmallocUsed:        9004 kB

VmallocChunk:      95740 kB

HugePages_Total:       0

HugePages_Free:        0

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

DirectMap4k:       14328 kB

DirectMap2M:      899072 kB

```

----------

## cach0rr0

normally the protocol is to, after you opt to throw a hardened kernel into the mix, switch a hardened profile, re-merge the toolchain, then merge emerge world

the resultant binaries should *still* operate fine under a normal kernel, but IIRC this is needed for them to behave correctly under a hardened kernel

----------

## Veldrin

Yes, I can confirm, that running a hardened system on a normal kernel works fine. 

I never tried the other way around (normal system on hardened kernel).

V.

----------

## mv

 *cach0rr0 wrote:*   

> normally the protocol is to, after you opt to throw a hardened kernel into the mix, switch a hardened profile, re-merge the toolchain, then merge emerge world

 

No, this is not necessary: Using "normal" binaries with a hardened kernel is fine. The binaries will just lack the special protection by PAX because they are not compiled with -fPIC.

----------

## nlsa8z6zoz7lyih3ap

 *Quote:*   

> Could you elaborate on the nature of the failure to boot? Specifically, was the vmdk intact and the guest filesystem trashed or was the vmdk itself broken? If the former, you would be able to boot a guest from a LiveCD, but likely not be able to access some or all of the guest filesystems. If the latter, VMware would likely refuse to open that guest at all.

 

It's hard to remember as all of that happened in 2008.  My original posting in this regard is https://forums.gentoo.org/viewtopic-p-5154743-highlight-.html#5154743        .

PS I just retested with the hardened-sources-2.6.39-r8 that was configured just like my current working gentoo-sources-2.6.39-r? kernel using make oldnoconfig Specifically all grsecurity and Pax features were disabled.. This time starting my  vmware guest crashed the host (gentoo)

to the extent that it shut off the power.  However upon a reboot to the gentoo-sources kernel, the guest OS started under vmware without difficulty.

My Conclusion: While I still have the highest regard for Grsecurity and Pax, since sometime in 2008 it does appear to make 

significant changes to the kernel just by being patched into the kernel, even if none of its features are enabled.

For this reason I no longer use it.  I do think that anyone trying it should have a complete backup of everything, including their host OS before trying it. If I were running a server rather than a home desktop I would, of course, use both Pax and Grsecurity with the RBAC. I really liked them when I was able to use them and wish that I still could.

----------

## cach0rr0

you are using vmware under hardened 

its very design implies interacting with kernel data structures in a way that PaX/grsec were intended to prevent

vmware should not be your benchmark for how well anything else is going to work under hardened

nor should, for example, the binary nvidia drivers

i make heavy use of virtual machines too; vmware-server went to absolute crap with 2.x, so between that, and issues under hardened, i myself opted for KVM over vmware-server. 

Either way, there seems to be the implication of, "well, vmware didnt work well under hardened, therefore most things dont work under hardened" - which is not true. Throwing external binary drivers into a hardened kernel is not a good idea in general, and i would fully expect these unique, one-off exceptional cases, to be less than straightforward.

Your issues have absolutely zero, nothing, nada, nil, to do with the stability of hardened. They have everything to do with vmware. There is no need to be more cautious with backups on hardened than you would with any other system (though, you should still as a practice do backups on 'any other system'). There is no legitimate reason to think that hardened is going to kill your dog or kick your babies or anything of the sort.

----------

## nlsa8z6zoz7lyih3ap

I believe that a careful reading of this topic would show that cach0rr0 has understood neither the content nor intent of my posts. I have written to him privately in this regard. I hope that this will be the end of public discussion on 

what he calls my  *Quote:*   

>  absolutely zero, nothing, nada, nil

   issues.

But I would like to ask:  Is cach0rr0 the moderator of this forum?

----------

## mv

This is a bit OT, but since some hardened-specialists seem to be reading:

Has anybody managed to compile clisp and fricas (with clisp) under a hardened kernel with x86?  Strange thing is that there is no obvious problem running the compiled binary and also no problem under amd64. However, under x86 it seems that some writable buffer should be executed which the kernel is blocking (therefore killing the compiling clisp process).

I guess if the binary is correspondingly marked with paxctl, it should work.

However, this marking should probably be done in the ebuild which contains no such thing.

Also marking /usr/bin/clisp, allowing everything, does not help compiling fricas which I do not understand at all.

----------

## D-LINC

Not to be selfish, but could we focus on the vmalloc problem I'm having?   :Smile:  Nothing about any vmalloc settings was mentioned in Gentoo's grsec documentation.

----------

## Hu

 *D-LINC wrote:*   

> Not to be selfish, but could we focus on the vmalloc problem I'm having?   Nothing about any vmalloc settings was mentioned in Gentoo's grsec documentation.

 It looks like you have a problem when the kernel decides to modprobe ipv6.  Presumably, your web server requested an IPv6 socket, which caused this.  The simplest approach would be to make ipv6 built-in if you want it or to disable it entirely if you do not want it.  Making it a module that gets loaded every time you boot is suboptimal.

----------

## nlsa8z6zoz7lyih3ap

I would like to thank cach0rr0 for the very helpful private discussions that we have had concerning my previous posts on this topic. He has made it clear to me that my posts do not reflect my real opinions and intent regarding the Hardened Gentoo project. For this I do sincerely apologize. Let me try to rectify this situation belatedly:

(1) In my opinion, the Gentoo-hardened project is one of the best things about Gentoo and certainly ( in my opinion) the best implementation of Pax, Grsecurity and security in general of which I am aware. Moreover Pax and Grsecurity are the only things of which I am aware that truly provide what I would consider to be good security. My use of them extends over many years. In fact I still run hardened on my laptop, but not on the other three  Gentoo machines which I maintain.

(2)  Ideally I believe that everyone should run at least PaX (and actually RBAC, which is easy to configure, too). 

(3) I have never had a serious problem with PaX on a machine that was only running the hardened-sources kernel

with no kernel modules from outside of it, such as the nvidia or vmware modules. In fact at times I have even used it with the nvidia module without major incidents, but I do not recommend doing so. If one is not using outside modules,

my personal recommendation is to use at least  PaX and better yet RBAC on any Gentoo system, Desktop, Workstation server or otherwise. Rest assured that because you are using Gentoo, you can choose the Gentoo hardened profile which with PaX etc, will give you an excellence of protection and an ease of implementing it that I am not aware of elsewhere, along with the wonderful Gentoo environment and collection of software in portage.

(4) However my experience has led me to see that if you are using proprietary modules + PaX then there is a possibility of doing serious damage. Such damage is completely  avoidable and the intent of my posts was to make it clear how to avoid it.  I  am very sorry if my posts gave a different impression and give special thanks to cach0rr0 for helping   me to see that they might have.

(5) I endorse Hu's excellent advice  *Quote:*   

> OP: given the ease with which one can switch between hardened and regular kernels of the same base revision, I encourage you to try hardened, especially if your kernel is not tainted. At worst, the machine will panic and require a switch back to a non-hardened kernel.
> 
> 

  I wish to apologize to Hu for putting my previous  comment on it as a disagreement.  I actually agree with Hu's advice, but just wanted to add the caveat that I advise doing backups before doing any such experimentation. While officially I advise against such experimentation,  I find it to be lots of fun.

Finally, I hope that D-LINC does try PaX. Others, including even myself, would be delighted to help you out if you have any further questions. I am sorry for the failings in my previous attempts to be helpful, and hope that I have "struck it right" this time.

----------

## D-LINC

 *Hu wrote:*   

>  *D-LINC wrote:*   Not to be selfish, but could we focus on the vmalloc problem I'm having?   Nothing about any vmalloc settings was mentioned in Gentoo's grsec documentation. It looks like you have a problem when the kernel decides to modprobe ipv6.  Presumably, your web server requested an IPv6 socket, which caused this.  The simplest approach would be to make ipv6 built-in if you want it or to disable it entirely if you do not want it.  Making it a module that gets loaded every time you boot is suboptimal.

 

Are there any ideas as to why an IPv6 module would not work under a hardened kernel? I guess I could just disable the module, but I'm still left curious as to what the problem is. Does anyone else have the IPv6 module built from a hardened kernel? Maybe you could load the module on your PC and see if it also crashes?

----------

## Hu

Based on the messages, I think the problem is that it cannot load a module, not that the module is ipv6.ko.  You have some problem such that modprobe just does not work at that stage.  It would be good to understand why it does not work, but since it seems that you will have IPv6 permanently loaded if you enable it at all, I suggested including it in the core kernel as a workaround.  You can also delete the module and set CONFIG_IPV6=n if you have no use for IPv6.

If you are asking whether I can use IPv6 on my machine, then yes, but I build with it set to =y, not =m as you have done, so the test is not a fair comparison.

----------

