linux-kernel - Re: [PATCH v2 0/4] Allow default HARDENED

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]

Message-ID: <ztewg4ohtq7iojoilwcuq2ozczfxv5gi2r3svh3l5n6fv6kvfl@etevudcdw7un>
Date: Thu, 23 Jan 2025 11:49:04 +0000
From: Mel Gorman <mgorman@...hsingularity.net>
To: Kees Cook <kees@...nel.org>
Cc: Daniel Micay <danielmicay@...il.com>, Paul Moore <paul@...l-moore.com>, 
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] Allow default HARDENED_USERCOPY to be set at
 compile time

On Wed, Jan 22, 2025 at 05:02:29PM -0800, Kees Cook wrote:
> 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. :)
> 

Almost certainly yes, it could be anything really but the results are
consistent. It'll be somewhat tricky to narrow down given that it's
somewhat specific to the CPU. It was outside the scope of the series to
investigate. The primary aim was to provide the option to have hardened
usercopy available, but not surprising from a performance perspective,
via a single kernel binary.

-- 
Mel Gorman
SUSE Labs