linux-kernel - Re: [PATCH v1 2/2] s390/pgtable: introduce _REGION3_ENTRY_HARDWARE_BITS

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]

Date: Fri, 26 Apr 2024 10:57:14 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
To: Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        gor@...ux.ibm.com, agordeev@...ux.ibm.com, svens@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, borntraeger@...ibm.com
Subject: Re: [PATCH v1 2/2] s390/pgtable: introduce
 _REGION3_ENTRY_HARDWARE_BITS_LARGE

On Thu, Apr 25, 2024 at 03:05:55PM +0200, Claudio Imbrenda wrote:
> For completeness, introduce _REGION3_ENTRY_HARDWARE_BITS_LARGE,
> containing the hardware bits used for large puds.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
> ---
>  arch/s390/include/asm/pgtable.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 3da2995fd196..5c0f840eee2a 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -262,6 +262,7 @@ static inline int is_module_addr(void *addr)
>  #define _REGION3_ENTRY		(_REGION_ENTRY_TYPE_R3 | _REGION_ENTRY_LENGTH)
>  #define _REGION3_ENTRY_EMPTY	(_REGION_ENTRY_TYPE_R3 | _REGION_ENTRY_INVALID)
>  
> +#define _REGION3_ENTRY_HARDWARE_BITS_LARGE	0xffffffff8000073cUL

_REGION_ENTRY_HARDWARE_BITS is missing too. :)

And this definition also raises the question if the definition of
_SEGMENT_ENTRY_HARDWARE_BITS_LARGE should be changed so it also includes
the table type bits, which it probably should.

These masks are really a bit randomly defined and assume that the
ACCF-Validity control bit is never set, and therefore the ACC bitfield can
be assumed to be software bits (and they are used as such for format 1
segment table entries).

But the ACCF bit is also a hardware bit in any case... oh well.