All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Daniel Micay <danielmicay@gmail.com>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mm: security: Move hardened usercopy under 'Kernel hardening options'
Date: Mon, 20 Jan 2025 13:10:44 -0800	[thread overview]
Message-ID: <202501201309.73DA8439B@keescook> (raw)
In-Reply-To: <20250117130337.4716-2-mgorman@techsingularity.net>

On Fri, Jan 17, 2025 at 01:03:35PM +0000, Mel Gorman wrote:
> 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>
> ---
>  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..00e6e2ed0c43 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -279,6 +279,22 @@ config ZERO_CALL_USED_REGS
>  
>  endmenu
>  
> +menu "String manipulation"

I think "string" means different things to different people. I'd prefer
"Bounds checking" or "Spatial safety" if it's going to be a separate
menu section.

> +
> +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"

Otherwise, looks good.

-- 
Kees Cook

  reply	other threads:[~2025-01-20 21:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-17 13:03 [PATCH 0/3] Allow default HARDENED_USERCOPY to be set at compile time Mel Gorman
2025-01-17 13:03 ` [PATCH 1/3] mm: security: Move hardened usercopy under 'Kernel hardening options' Mel Gorman
2025-01-20 21:10   ` Kees Cook [this message]
2025-01-21  9:21     ` Mel Gorman
2025-01-20 21:42   ` Paul Moore
2025-01-17 13:03 ` [PATCH 2/3] mm: security: Allow default HARDENED_USERCOPY to be set at compile time Mel Gorman
2025-01-20 21:21   ` Kees Cook
2025-01-21 12:35     ` Mel Gorman
2025-01-17 13:03 ` [PATCH 3/3] fortify: Move FORTIFY_SOURCE under 'Kernel hardening options' Mel Gorman
2025-01-20 21:25   ` Kees Cook
2025-01-20 21:08 ` [PATCH 0/3] Allow default HARDENED_USERCOPY to be set at compile time Kees Cook

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=202501201309.73DA8439B@keescook \
    --to=kees@kernel.org \
    --cc=danielmicay@gmail.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    /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.