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>,
	Paul Moore <paul@paul-moore.com>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Allow default HARDENED_USERCOPY to be set at compile time
Date: Wed, 22 Jan 2025 17:02:29 -0800	[thread overview]
Message-ID: <202501221701.61D4E17@keescook> (raw)
In-Reply-To: <20250122171925.25472-1-mgorman@techsingularity.net>

On Wed, Jan 22, 2025 at 05:19:21PM +0000, Mel Gorman wrote:
> on the exact CPU. While the benchmarks are somewhat synthetic, the overhead
> IO-intensive and network-intensive is easily detectable but the root cause
> may not be obvious (e.g. 2-14% overhead for netperf TCP_STREAM running
> over localhost with different ranges depending on the CPU).

I would be curious to see where this overhead is coming from. That seems
extraordinarily high, and makes me think there is something more we
should be fixing. :)

-- 
Kees Cook

  parent reply	other threads:[~2025-01-23  1:02 UTC|newest]

Thread overview: 13+ 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 ` [PATCH 1/4] mm: security: Move hardened usercopy under 'Kernel hardening options' Mel Gorman
2025-01-22 17:19 ` [PATCH 2/4] mm: security: Allow default HARDENED_USERCOPY to be set at compile time 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 ` Kees Cook [this message]
2025-01-23 11:49   ` [PATCH v2 0/4] Allow default HARDENED_USERCOPY to be set at compile time 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=202501221701.61D4E17@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 \
    --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.