linux-kernel - Re: [RFC PATCH v5 00/18] pkeys-based page table hardening

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: <3c18d1f1e94d3491410168e37cdf67e9e471649e.camel@intel.com>
Date: Wed, 20 Aug 2025 16:18:19 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kevin.brodsky@....com" <kevin.brodsky@....com>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
CC: "maz@...nel.org" <maz@...nel.org>, "luto@...nel.org" <luto@...nel.org>,
	"willy@...radead.org" <willy@...radead.org>, "mbland@...orola.com"
	<mbland@...orola.com>, "david@...hat.com" <david@...hat.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"rppt@...nel.org" <rppt@...nel.org>, "joey.gouly@....com"
	<joey.gouly@....com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "Weiny, Ira" <ira.weiny@...el.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "pierre.langlois@....com"
	<pierre.langlois@....com>, "jeffxu@...omium.org" <jeffxu@...omium.org>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>, "kees@...nel.org"
	<kees@...nel.org>, "ryan.roberts@....com" <ryan.roberts@....com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "jannh@...gle.com"
	<jannh@...gle.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "will@...nel.org" <will@...nel.org>,
	"qperret@...gle.com" <qperret@...gle.com>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "broonie@...nel.org" <broonie@...nel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH v5 00/18] pkeys-based page table hardening

On Wed, 2025-08-20 at 18:01 +0200, Kevin Brodsky wrote:
> Apologies, Thunderbird helpfully decided to wrap around that table...
> Here's the unmangled table:
> 
> +-------------------+----------------------------------+------------------+---------------+
> > Benchmark         | Result Class                     | Without batching | With batching |
> +===================+==================================+==================+===============+
> > mmtests/kernbench | real time                        |            0.32% |         0.35% |
> >                    | system time                      |        (R) 4.18% |     (R) 3.18% |
> >                    | user time                        |            0.08% |         0.20% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/fork      | fork: h:0                        |      (R) 221.39% |     (R) 3.35% |
> >                    | fork: h:1                        |      (R) 282.89% |     (R) 6.99% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/munmap    | munmap: h:0                      |       (R) 17.37% |        -0.28% |
> >                    | munmap: h:1                      |      (R) 172.61% |     (R) 8.08% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/vmalloc   | fix_size_alloc_test: p:1, h:0    |       (R) 15.54% |    (R) 12.57% |

Both this and the previous one have the 95% confidence interval. So it saw a 16%
speed up with direct map modification. Possible?

> >                    | fix_size_alloc_test: p:4, h:0    |       (R) 39.18% |     (R) 9.13% |
> >                    | fix_size_alloc_test: p:16, h:0   |       (R) 65.81% |         2.97% |
> >                    | fix_size_alloc_test: p:64, h:0   |       (R) 83.39% |        -0.49% |
> >                    | fix_size_alloc_test: p:256, h:0  |       (R) 87.85% |    (I) -2.04% |
> >                    | fix_size_alloc_test: p:16, h:1   |       (R) 51.21% |         3.77% |
> >                    | fix_size_alloc_test: p:64, h:1   |       (R) 60.02% |         0.99% |
> >                    | fix_size_alloc_test: p:256, h:1  |       (R) 63.82% |         1.16% |
> >                    | random_size_alloc_test: p:1, h:0 |       (R) 77.79% |        -0.51% |
> >                    | vm_map_ram_test: p:1, h:0        |       (R) 30.67% |    (R) 27.09% |
> +-------------------+----------------------------------+------------------+---------------+

Hmm, still surprisingly low to me, but ok. It would be good have x86 and arm
work the same, but I don't think we have line of sight to x86 currently. And I
actually never did real benchmarks.