linux-kernel - Re: [PATCH 1/4] pkeys: add API to switch to permissive pkey register

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] [day] [month] [year] [list]

Message-ID: <CACT4Y+arkwVHQcbcFDZdLuZeJeued4gwxNYXT7rWsVJDsVjj1g@mail.gmail.com>
Date: Thu, 27 Feb 2025 14:58:22 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: mathieu.desnoyers@...icios.com, peterz@...radead.org, boqun.feng@...il.com, 
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, hpa@...or.com, aruna.ramakrishna@...cle.com, 
	elver@...gle.com, "Paul E. McKenney" <paulmck@...nel.org>, x86@...nel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] pkeys: add API to switch to permissive pkey register

On Wed, 26 Feb 2025 at 18:21, Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 2/26/25 02:00, Dmitry Vyukov wrote:
> >> We could typedef it to some fake struct. Such a struct can't be passed
> >> to any function accepting an integer type (real pkeys), and any
> >> arithmetic won't work on it.
> > Dave, how should we proceed? Do you think this is a potential misuse
> > worth preventing proactively? If yes, I can send v7.
>
> I don't think it's worth doing anything too weird. Defining some kind of
> special struct would be pretty weird.

Isn't sparse-specific attributes, or address spaces more weird that a
normal C struct?
If you suggest a concrete type I can re-send the series with the
change. But for now I am going to leave it as it is. A fact that a bug
may be introduced does not mean it will be introduced (there is an
infinite set of possible bugs that can be introduced in future, and
generally there is no reliable way to ensure no bugs will be
introduced, or we would have 0 bugs in the kernel :)).