http://bugzilla.opensuse.org/show_bug.cgi?id=1127808 Bug ID: 1127808 Summary: Please consider CONFIG_HARDENED_USERCOPY and CONFIG_SLAB_FREELIST_HARDENED Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Linux Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: eppers@posteo.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- This proposal has been posted already on the relevant mailing list: "https://lists.opensuse.org/opensuse-kernel/2019-03/msg00001.html" Please apologize if I've chosen the wrong channel for the proposal. The text of the email follows below for your convenience: I would like to propose two new compile time settings. CONFIG_HARDENED_USERCOPY=y CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y # CONFIG_HARDENED_USERCOPY_FALLBACK is not set # CONFIG_HARDENED_USERCOPY_PAGESPAN is not set This option checks for obviously wrong memory regions when copying memory to/from the kernel (via copy_to_user() and copy_from_user() functions) by rejecting memory ranges that are larger than the specified heap object, span multiple separately allocated pages, are not on the process stack, or are part of the kernel text. This kills entire classes of heap overflow exploits and similar kernel memory exposures. Debian, Ubuntu and CentOS build their kernels like this by default, which I think underlines the general usefulness. The performance penalty has been reported to be very small or not measurable in common scenarios. There have been, though, issues with networking performance under heavy load, which led to the introduction of a hardened_usercopy=off boot parameter (commit b5cb15d9372abc9adc4e844c0c1bf594ca6a7695). CONFIG_SLAB_FREELIST_HARDENED=y Many kernel heap attacks try to target slab cache metadata and other infrastructure. This options makes minor performance sacrifies to harden the kernel slab allocator against common freelist exploit methods. Debian and Ubuntu build their kernels with this enabled. According to Kees Cook, the performance penalty is almost immeasurably small: https://lkml.org/lkml/2017/7/26/4 Thanks for consideration. -- You are receiving this mail because: You are on the CC list for the bug.