#grsecurity — Public Fediverse posts

Preparatory patches: https://github.com/NVIDIA/open-gpu-kernel-modules/pull/1068

Full Kbuild support: https://github.com/NVIDIA/open-gpu-kernel-modules/pull/1069

#grsecurity compatibility: https://github.com/NVIDIA/open-gpu-kernel-modules/pull/1070

Our 6.18 #grsecurity LTS release, to be supported through at least the end of 2028, is now available!

6.18 has been selected as the next #grsecurity stable kernel version, to be supported through the end of 2028, one year longer than the upstream LTS EOL date of Dec 2027.

Nice demo: tested a vulnerable Ubuntu 22.04 system for glibc CVE-2025-4802 using Solar Designer's PoC adapted to Ubuntu (replace any occurrence of "myhostname" with "mdns4_minimal"). Even an old #grsecurity 5.4.96 kernel from February 8 2021 prevented exploitation

We expect our 6.13 #grsecurity beta to be available within the next two weeks.

Our 6.12 #grsecurity beta is now available to beta testers for testing

Linux kernel hardening does not necessarily have to ruin performance. Quite the opposite is possible! One just has to address performance issues first and gets better security “for free” — sometimes vast performance improvements even!

Current example: BPF JIT handling. test_bpf.ko is a kernel module exercising various extreme and corner cases of BPF programs the kernel is supposed to handle just fine. However, under certain configurations it makes the kernel busy burn cycles without making real progress. Fixing that allowed us to implement security features in #grsecurity at all stages of the JIT process and basically get them for free. See for yourself…

…and yes, while waiting for insmod to finish on vanilla Linux, I fixed the tests and did a quick re-run on #grsecurity.

Performance isn't the enemy of security: we care about both. Today's patches finish off a set of security/performance improvements to eBPF. Below we show a ~30x speedup vs vanilla in running the eBPF selftests with every single #grsecurity option enabled!

I wrote about how C‘s more recent language features make grsecurity maintenance easier and how we pushed the idea even further by adding a new compiler builtin.

https://grsecurity.net/reducing_maintenance_burden_by_bending_c

The article has quite some code snippets, showing how easy the latter actually is, thanks to a rather stable GCC plugin API.

#grsecurity #gcc #C

@paulmckrcu, regarding https://lore.kernel.org/kvm/08ee7eb2-8d08-4f1f-9c46-495a544b8c0e@paulmck-laptop/, we went with option 3 and implemented rcu_kvfree_barrier() in #grsecurity, mainly in need for AUTOSLAB which converts every kmalloc() into a dedicated slab cache, making the issue much more likely to trigger. Placing a call to rcu_kvfree_barrier() at a fitting place in free_module() fixes the leak/uaf issue.

While Zi Gan Tan walks the #OffensiveCon crowd through his Binder exploit, I’ve identified no less than 7 independent features in #grsecurity that break it:

1/ slab merging is disabled by default and
2/ AUTOSLAB makes it impossible to move any allocation into a kmalloc slab cache.
3/ DYNORDER breaks moving free’d slab pages to a different cache easily as well as
4/ our modifications to the free page buddy handling make it even harder to reallocate recently freed pages.
5/ Type canaries detect the file related type confusion, breaking the leak primitive.
6/ KERNSEAL will prevent messing with cred objects (they’re r/o), so does
7/ CONSTIFY for selinux_state.

#sad-state-of-android-security

Busca por ahí una comparativa de rendimiento entre zócalos Unix, IP, tuberías con nombre y anónimas y luego me cuentas para qué sirve cada cosa. Y ya de paso revisas la opinión de Torvalds con respecto a conjuntos de parches como #grsecurity (https://www.theregister.com/2017/06/26/linus_torvalds_slams_pure_garbage_from_clowns_at_grsecurity/).

New PaXtest release after years of silence 🥳

Git source: https://github.com/opensrcsec/paxtest/

Small announcement: https://grsecurity.net/paxtest_release/ (worth a read, contains even more info than what’s written about 😛)

#grsecurity #PaX #testing #ASLR

@OS1337 Honestly, it really looks like your description is skewed in a very anti-GPL way... ugh...

> Interestingly, all the people that say "#Copilot is violating my #Copyright!" and fanboy #BusyBox's hamfisted approach to #GPLv2 enforcement are really quiet when it comes to enforcing #GPLv2 against #RedHat or #grsecurity...

Not true.

- For Red Hat, they are allowed to sell copies - See: https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
- For grsecurity, people have complained... a lot.

@jvoisin thanks for the mention, but I don’t think that adding support for something like GFP_USERCOPY to neuter the well-known exploit type vectors (msg_msg, xattr, etc.) is all that hard when one‘s already started providing multiple kmalloc hierarchies. It’s just another dimension and that code can even be copycated from the old #grsecurity patches.

📬Linux Kernel: Wollte Huawei absichtlich eine Hintertür einbauen?📬 https://tarnkappe.info/linux-kernel-wollte-huawei-absichtlich-eine-hintertuer-einbauen/ #HuaweiKernelSelfProtection #Grsecurity #Artikel #Huawei #Linux #HKSP