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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d352ab70-6c13-453b-a018-dcf19d1a9924@intel.com>
Date: Tue, 25 Feb 2025 08:15:57 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Dmitry Vyukov <dvyukov@...gle.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 2/24/25 05:25, Dmitry Vyukov wrote:
>>> +#ifndef CONFIG_ARCH_HAS_PERMISSIVE_PKEY
>>> +
>>> +/*
>>> + * Common name for value of the register that controls access to PKEYs
>>> + * (called differently on different arches: PKRU, POR, AMR).
>>> + */
>>> +typedef int pkey_reg_t;
>> Tiny nit: Should this be an unsigned type?
>>
>> Nobody should be manipulating it, but I'd be surprised if any of the
>> architectures have a signed type for it.
> Since this is a stub type, can matching the real types do any good
> besides masking programming errors?
> I've changed it to char in v4 to surface more potential programming errors.

I was more worried about copy-and-paste.

I agree that 'char' is the most fragile, but it's going to fragile in
subtle ways and I'm not sure subtly broken code (whether it's expected
to be compiled in or not) is great to have in a code base.

Do we have any types in sparse that would be appropriate? Could we mark
the pkey_reg_t as being in a different address space when pkeys is
compiled out so that sparse knows not to let it interact with other types?