lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Sep 2023 10:59:27 +0000
From:   Matteo Rizzo <matteorizzo@...gle.com>
To:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org, vbabka@...e.cz,
        roman.gushchin@...ux.dev, 42.hyeyoo@...il.com,
        keescook@...omium.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-hardening@...r.kernel.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, corbet@....net, luto@...nel.org,
        peterz@...radead.org
Cc:     jannh@...gle.com, matteorizzo@...gle.com, evn@...gle.com,
        poprdi@...gle.com, jordyzomer@...gle.com
Subject: [RFC PATCH 08/14] security: introduce CONFIG_SLAB_VIRTUAL

From: Jann Horn <jannh@...gle.com>

SLAB_VIRTUAL is a mitigation for the SLUB allocator which prevents reuse
of virtual addresses across different slab caches and therefore makes
some types of use-after-free bugs unexploitable.

SLAB_VIRTUAL is incompatible with KASAN and we believe it's not worth
adding support for it. This is because SLAB_VIRTUAL and KASAN are aimed
at two different use cases: KASAN is meant for catching bugs as early as
possible in debug/fuzz/testing builds, and it's not meant to be used in
production. SLAB_VIRTUAL on the other hand is an exploit mitigation that
doesn't attempt to highlight bugs but instead tries to make them
unexploitable. It doesn't make sense to enable it in debugging builds or
during fuzzing, and instead we expect that it will be enabled in
production kernels.

SLAB_VIRTUAL is not currently compatible with KFENCE, removing this
limitation is future work.

Signed-off-by: Jann Horn <jannh@...gle.com>
Co-developed-by: Matteo Rizzo <matteorizzo@...gle.com>
Signed-off-by: Matteo Rizzo <matteorizzo@...gle.com>
---
 security/Kconfig.hardening | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 0f295961e773..9f4e6e38aa76 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -355,4 +355,18 @@ config GCC_PLUGIN_RANDSTRUCT
 	   * https://grsecurity.net/
 	   * https://pax.grsecurity.net/
 
+config SLAB_VIRTUAL
+	bool "Allocate slab objects from virtual memory"
+	depends on SLUB && !SLUB_TINY
+	# If KFENCE support is desired, it could be implemented on top of our
+	# virtual memory allocation facilities
+	depends on !KFENCE
+	# ASAN support will require that shadow memory is allocated
+	# appropriately.
+	depends on !KASAN
+	help
+	  Allocate slab objects from kernel-virtual memory, and ensure that
+	  virtual memory used as a slab cache is never reused to store
+	  objects from other slab caches or non-slab data.
+
 endmenu
-- 
2.42.0.459.ge4e396fd5e-goog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ