linux-kernel - Re: [RFC v2 26/35] RPAL: enable MPK support

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: <ae794a43-19d0-4c51-a7bc-96427feac5e6@intel.com>
Date: Fri, 30 May 2025 10:03:08 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Bo Li <libo.gcs85@...edance.com>, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, luto@...nel.org,
 kees@...nel.org, akpm@...ux-foundation.org, david@...hat.com,
 juri.lelli@...hat.com, vincent.guittot@...aro.org, peterz@...radead.org
Cc: dietmar.eggemann@....com, hpa@...or.com, acme@...nel.org,
 namhyung@...nel.org, mark.rutland@....com,
 alexander.shishkin@...ux.intel.com, jolsa@...nel.org, irogers@...gle.com,
 adrian.hunter@...el.com, kan.liang@...ux.intel.com, viro@...iv.linux.org.uk,
 brauner@...nel.org, jack@...e.cz, lorenzo.stoakes@...cle.com,
 Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
 mhocko@...e.com, rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
 vschneid@...hat.com, jannh@...gle.com, pfalcato@...e.de, riel@...riel.com,
 harry.yoo@...cle.com, linux-kernel@...r.kernel.org,
 linux-perf-users@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, duanxiongchun@...edance.com, yinhongbo@...edance.com,
 dengliang.1214@...edance.com, xieyongji@...edance.com,
 chaiwen.cc@...edance.com, songmuchun@...edance.com, yuanzhu@...edance.com,
 chengguozhu@...edance.com, sunjiadong.lff@...edance.com
Subject: Re: [RFC v2 26/35] RPAL: enable MPK support

On 5/30/25 02:27, Bo Li wrote:
> RPAL leverages Memory Protection Keys (MPK) to safeguard shared memory
> from illegal access and corruption by other processes. 

... as long as nobody uses the completely unprivileged WRPKRU or XRSTOR
instructions. Right?

... the instructions that are plainly available in super obscure
libraries like glibc?

This seems like a rather major oversight.

Oh, speaking of major oversights, you stymied pkey_alloc() but forgot
pkey_free(). There's nothing to stop folks from pkey_free()'ing a pkey
that RPAL is using and then letting someone else allocate it.

Is this all for real and serious?