segfaults upon install of uBlock0 in Pale Moon on grsecunoff kernel-based Linux

[miroR]

So tired that I'm only posting links (all links go from there): https://github.com/gorhill/uBlock/issues/3530 grsecunoff must live, GNU/Linux on google-sponsored security would be/almost is (it's happening, God!) worse than death of GNU/Linux!

[miroR]

Here's the kernel on which it happen. I have AMD64 processors only in my active machines, which should not be at such great risk from Spectre (and is not at all at risk from Meltdown) attacks. Also, the microcode to mitigate is just not published yet, for medium to old processors (fam16 and fam15). The 4.9.74 kernel is similar to the all-hardware that I uploaded packages for people to use at https://croatiafidelis.hr/gnu/deb/linux-image-4.9.74-grsecunoff-180204-21/ except it's only my hardware and no modules loading. Here's parts of the config (contains unabbreviated grsecurity section):

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.9.74 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
[...]

#
# General setup
[...]
CONFIG_LOCALVERSION="180216-23"
[...]
CONFIG_HAVE_GCC_PLUGINS=y
CONFIG_GCC_PLUGINS=y
# CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is not set
CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
[...]
# GCOV-based kernel profiling
#
[...]
# CONFIG_MODULES is not set
[...]
# Security options
#

#
# Grsecurity
#
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_TASK_SIZE_MAX_SHIFT=42
CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CONFIG_AUTO=y
# CONFIG_GRKERNSEC_CONFIG_CUSTOM is not set
# CONFIG_GRKERNSEC_CONFIG_SERVER is not set
CONFIG_GRKERNSEC_CONFIG_DESKTOP=y
# CONFIG_GRKERNSEC_CONFIG_VIRT_NONE is not set
# CONFIG_GRKERNSEC_CONFIG_VIRT_GUEST is not set
CONFIG_GRKERNSEC_CONFIG_VIRT_HOST=y
CONFIG_GRKERNSEC_CONFIG_VIRT_EPT=y
# CONFIG_GRKERNSEC_CONFIG_VIRT_SOFT is not set
# CONFIG_GRKERNSEC_CONFIG_VIRT_XEN is not set
# CONFIG_GRKERNSEC_CONFIG_VIRT_VMWARE is not set
CONFIG_GRKERNSEC_CONFIG_VIRT_KVM=y
# CONFIG_GRKERNSEC_CONFIG_VIRT_VIRTUALBOX is not set
# CONFIG_GRKERNSEC_CONFIG_VIRT_HYPERV is not set
# CONFIG_GRKERNSEC_CONFIG_PRIORITY_PERF is not set
CONFIG_GRKERNSEC_CONFIG_PRIORITY_SECURITY=y

#
# Default Special Groups
#
CONFIG_GRKERNSEC_PROC_GID=1001
CONFIG_GRKERNSEC_TPE_UNTRUSTED_GID=1005

#
# Customize Configuration
#

#
# PaX
#
CONFIG_PAX=y

#
# PaX Control
#
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_XATTR_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_MPROTECT_COMPAT is not set
# CONFIG_PAX_ELFRELOCS is not set
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN=y
# CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_NONE is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_BTS=y
# CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is not set

#
# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

#
# Miscellaneous hardening features
#
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_STRUCTLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_USERCOPY=y
CONFIG_PAX_CONSTIFY_PLUGIN=y
# CONFIG_PAX_USERCOPY_DEBUG is not set
CONFIG_PAX_SIZE_OVERFLOW=y
CONFIG_PAX_SIZE_OVERFLOW_EXTRA=y
# CONFIG_PAX_INITIFY is not set
CONFIG_HAVE_PAX_INITIFY_INIT_EXIT=y
CONFIG_PAX_LATENT_ENTROPY=y
CONFIG_PAX_RAP=y
CONFIG_PAX_RAP_VERBOSE=y

#
# Memory Protections
#
CONFIG_GRKERNSEC_KMEM=y
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_BPF_HARDEN=y
CONFIG_GRKERNSEC_PERF_HARDEN=y
CONFIG_GRKERNSEC_RAND_THREADSTACK=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_KSTACKOVERFLOW=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_RANDSTRUCT=y
# CONFIG_GRKERNSEC_RANDSTRUCT_PERFORMANCE is not set
CONFIG_GRKERNSEC_KERN_LOCKOUT=y

#
# Role Based Access Control Options
#
# CONFIG_GRKERNSEC_NO_RBAC is not set
# CONFIG_GRKERNSEC_ACL_HIDEKERN is not set
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
# CONFIG_GRKERNSEC_SYMLINKOWN is not set
CONFIG_GRKERNSEC_FIFO=y
# CONFIG_GRKERNSEC_SYSFS_RESTRICT is not set
# CONFIG_GRKERNSEC_ROFS is not set
CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_RENAME=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_CHROOT_INITRD=y

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_PTRACE=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_RWXMAP_LOG=y

#
# Executable Protections
#
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_PTRACE_READEXEC=y
CONFIG_GRKERNSEC_SETXID=y
CONFIG_GRKERNSEC_HARDEN_IPC=y
CONFIG_GRKERNSEC_HARDEN_TTY=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
# CONFIG_GRKERNSEC_TPE_INVERT is not set
CONFIG_GRKERNSEC_TPE_GID=1005

#
# Network Protections
#
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
# CONFIG_GRKERNSEC_SOCKET is not set

#
# Physical Protections
#
CONFIG_GRKERNSEC_DENYUSB=y
# CONFIG_GRKERNSEC_DENYUSB_FORCE is not set

#
# Sysctl Support
#
CONFIG_GRKERNSEC_SYSCTL=y
CONFIG_GRKERNSEC_SYSCTL_ON=y

#
# Logging Options
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=6
CONFIG_KEYS=y
CONFIG_KEYS_COMPAT=y
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEY_DH_OPERATIONS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_HAVE_ARCH_HARDENED_USERCOPY=y
CONFIG_HARDENED_USERCOPY=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_ASYNC_PQ=y
CONFIG_ASYNC_RAID6_RECOV=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
[...]

Any advice what to look in, what to try to get this issue undersood/solved appreciated.

[gitbugged]

GNU/Linux on google-sponsored security would be/almost is (it's happening, God!)

Completely agree. Sadly, Google has invaded GNU/Linux and is actively working to destroy it, both on the browser and kernel fronts. Brad Spender is no exception to amplifying the problem by asking for $4,000 for a "subscription" service for the latest patches, under NDA. Greed is killing the F/LOSS community.

Any advice what to look in, what to try to get this issue undersood/solved appreciated.

I don't believe this is a grsecurity issue, it is a browser issue as the ublock ticket said. Pale Moon is coded by a single dev and he has made a few bugs, which is causing the crash. I'm hanging out on FF52 ESR with privacy patches until forced to jump to Ungoogled-Chromium or something better comes along.

[miroR]

@gitbugged

Brad Spender is no exception to amplifying the problem by asking for $4,000 for a "subscription" service for the latest patches, under NDA. Greed is killing the F/LOSS community.

Spender and PaX Team lost patience with the prevalent lack of common sense in us, the Free Open Source GNU/Linux community.Who tried to understand what went on, and where was the backing to them from us, the free people of the GNU/Linux computing?

GNU/Linux could be made secure only thanks to the methods they have brought into the industry. And those ways are still the only right ways to get GNU/Linux secure.

I for one, but I'm not an expert and my voice can not be regarded as important, tried ever since I started using grsecurity, to spread the truth about it.

But where was enough understanding in the GNU/Linux community to give credit where credit was due, and that is to PaX Team and spender?

Instead, what we had is the Dear Leader, all over, wherever he felt like, denigrating them like dirt, and underhandedly suggesting to devs to not properly give them credit for their code when they were --because there was no other way (there still is no other way, I don't think) to properly protect the kernel-- when they were using their code.

Why on Earth should they then be bound to a community that treated them/allowed such treatment of them?

It just had to end. I wish they come back some day, but they are not bound to do that "out of respect for their former users" as @HacKurx said in another issue these days.

I wish the leaders of various projects in GNU/Linux community were better people, and admitted the importance of securing Linux... and admitted the huge benefit spender and PaX Team brought into the community with their change to the industry...

And then there is Google. Google who deliberately enticed them to contribute to KSPP, but never ever paying a dime to them... And it's their code which is the backbone of KSPP...

And that guy who is the leader of KSPP maybe outright lying (I'm not claiming he lied, but how could he had been that poorly misinformed to not know they weren't paid, nor ever offered any payment from Google, how could he, the leader of KSPP?, correct me if I'm wrong) maybe even lying that they were offered from Google to be paid, but that they refused...

But I should be linking where I indirectly quote people in the text above, but... no time.

Instead, pls. look up my signature on Devuan Forums, say in the topic: Grsecurity/Pax installation on Devuan GNU/Linux https://dev1galaxy.org/viewtopic.php?id=596 and go from there. All that I wrote should be verifiable.

[miroR]

By the way, it's Brad Spengler, spender being his nickname.

[miroR]

Ah, the signature is not at the top of the page I linked, So reproduing it here:

Devs/testers/users of FOSS, what might be ahead for GNU/Linux after we lost PaX Team and spender? spender wrote: https://forums.grsecurity.net/viewtopic.php?f=3&t=4699#p17127 Google made the choice to engage in underhanded competition against us with our own code...

grsecurity ripoff by Google, w/ Linus approval https://lists.dyne.org/lurker/message/20170627.120949.727e804b.en.html

Everybody needs to know this. The abuse was way too much...

[theLOICofFRANCE]

@miroR

And then there is Google. Google who deliberately enticed them to contribute to KSPP, but never ever paying a dime to them... And it's their code which is the backbone of KSPP...

Yes, I think I made myself clear at the time: kernel-hardening/2015/12/11/11

Now what's done is done. Now don't forget that you are using an unofficial version of a guy who works at Google ^^

But he is beautiful, big and strong 💪 and hard work for us ^^ @minipli Your beer's still here:

.sssssssss. .sssssssssssssssssss sssssssssssssssssssssssss ssssssssssssssssssssssssssss @@sssssssssssssssssssssss@ss |s@@@@sssssssssssssss@@@@s|s ___|sssss@@@@@sssss@@@@@sssss|s / sssssssss@sssss@sssssssss|s / .------+.ssssssss@sssss@ssssssss.| / / |...sssssss@sss@sssssss...| | | |.......sss@sss@ssss......| | | |..........s@ss@sss.......| | | |...........@ss@..........| \ \ |............ss@..........| \ '------+...........ss@...........| ____ .........................| |.........................| /...........................\ |.............................| |.......................| |...............|

           __         __  __ ___      __   __  __  __
          |_  | |\ | |_  (_   |      |__) |_  |_  |__)
          |   | | \| |__ __)  |      |__) |__ |__ | \                         cfbd

[miroR]

Yes, I think I made myself clear at the time: http://www.openwall.com/lists/kernel-hardening/2015/12/11/11

Some of those Intel/Intel daughter firm, let me bring the last post in that thread (still with all the links you gave them): http://www.openwall.com/lists/kernel-hardening/2015/12/13/1 still shamelessly feature grsecurity all over those docs, and others lead elsewhere, to non-related content.

And Jakob Appelbaum twitter post, yeah, Jakob is a great leader too!

Now what's done is done. Now don't forget that you are using an unofficial version of a guy who works at Google ^^

O my! Really? I didn't know that. And now that I do (pls comebody confirm this, it feels almost phantasmagoric), I can stop bashing them, but only when minipli is around :) . But I'm half serious... But no, they can't buy his soul, and they didn't...

[miroR]

By the way, the issue that I opened this for, is not due to any fault of grsecunoff. I'll post about it at: Installing uBlock Origin breaks Pale Moon on grsec-hardened kernel https://forum.palemoon.org/viewtopic.php?f=46&t=18389&p=135431 In short, it was a compiler issue. Pale Moon must be compiled with gcc-4 and g++-4. So I'll close this issue. But elder members (by knowledge) may reopen it as far as I'm concerned even if it be for reasons of commenting about the truth of grsec and it's fate.