From: Mel Gorman <mgorman@techsingularity.net>
To: Kees Cook <kees@kernel.org>
Cc: Daniel Micay <danielmicay@gmail.com>,
Paul Moore <paul@paul-moore.com>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
Mel Gorman <mgorman@techsingularity.net>
Subject: [PATCH 1/4] mm: security: Move hardened usercopy under 'Kernel hardening options'
Date: Wed, 22 Jan 2025 17:19:22 +0000 [thread overview]
Message-ID: <20250122171925.25472-2-mgorman@techsingularity.net> (raw)
In-Reply-To: <20250122171925.25472-1-mgorman@techsingularity.net>
There is a submenu for 'Kernel hardening options' under "Security".
Move HARDENED_USERCOPY under the hardening options as it is clearly
related.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Paul Moore <paul@paul-moore.com>
---
security/Kconfig | 12 ------------
security/Kconfig.hardening | 16 ++++++++++++++++
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/security/Kconfig b/security/Kconfig
index 28e685f53bd1..fe7346dc4bc3 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -159,18 +159,6 @@ config LSM_MMAP_MIN_ADDR
this low address space will need the permission specific to the
systems running LSM.
-config HARDENED_USERCOPY
- bool "Harden memory copies between kernel and userspace"
- imply STRICT_DEVMEM
- help
- 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 prevents entire classes
- of heap overflow exploits and similar kernel memory exposures.
-
config FORTIFY_SOURCE
bool "Harden common str/mem functions against buffer overflows"
depends on ARCH_HAS_FORTIFY_SOURCE
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index c9d5ca3d8d08..9088d613d519 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -279,6 +279,22 @@ config ZERO_CALL_USED_REGS
endmenu
+menu "Bounds checking"
+
+config HARDENED_USERCOPY
+ bool "Harden memory copies between kernel and userspace"
+ imply STRICT_DEVMEM
+ help
+ 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 prevents entire classes
+ of heap overflow exploits and similar kernel memory exposures.
+
+endmenu
+
menu "Hardening of kernel data structures"
config LIST_HARDENED
--
2.43.0
next prev parent reply other threads:[~2025-01-22 17:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 17:19 [PATCH v2 0/4] Allow default HARDENED_USERCOPY to be set at compile time Mel Gorman
2025-01-22 17:19 ` Mel Gorman [this message]
2025-01-22 17:19 ` [PATCH 2/4] mm: security: " Mel Gorman
2025-01-23 0:57 ` Kees Cook
2025-01-23 11:37 ` Mel Gorman
2025-01-23 21:10 ` David Laight
2025-01-22 17:19 ` [PATCH 3/4] mm: security: Check early if HARDENED_USERCOPY is enabled Mel Gorman
2025-01-23 1:01 ` Kees Cook
2025-01-23 11:47 ` Mel Gorman
2025-01-22 17:19 ` [PATCH 4/4] fortify: Move FORTIFY_SOURCE under 'Kernel hardening options' Mel Gorman
2025-01-22 21:42 ` Paul Moore
2025-01-23 1:02 ` [PATCH v2 0/4] Allow default HARDENED_USERCOPY to be set at compile time Kees Cook
2025-01-23 11:49 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2025-01-23 22:11 [PATCH v3 " Mel Gorman
2025-01-23 22:11 ` [PATCH 1/4] mm: security: Move hardened usercopy under 'Kernel hardening options' Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250122171925.25472-2-mgorman@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=danielmicay@gmail.com \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.