linux-kernel - Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87y13mnc57.fsf@mail.lhotse>
Date: Fri, 20 Sep 2024 15:10:28 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Christophe Leroy
 <christophe.leroy@...roup.eu>, Arnd Bergmann <arnd@...db.de>, Richard
 Henderson <richard.henderson@...aro.org>, Ivan Kokshaysky
 <ink@...assic.park.msu.ru>, Matt Turner <mattst88@...il.com>, Vineet Gupta
 <vgupta@...nel.org>, Russell King <linux@...linux.org.uk>, Guo Ren
 <guoren@...nel.org>, Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui
 <kernel@...0n.name>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>, Helge
 Deller <deller@....de>, Nicholas Piggin <npiggin@...il.com>, Naveen N Rao
 <naveen@...nel.org>, Alexander Gordeev <agordeev@...ux.ibm.com>, Gerald
 Schaefer <gerald.schaefer@...ux.ibm.com>, Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Christian
 Borntraeger <borntraeger@...ux.ibm.com>, Sven Schnelle
 <svens@...ux.ibm.com>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich
 Felker <dalias@...c.org>, John Paul Adrian Glaubitz
 <glaubitz@...sik.fu-berlin.de>, "David S. Miller" <davem@...emloft.net>,
 Andreas Larsson <andreas@...sler.com>, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, Muchun Song <muchun.song@...ux.dev>,
 Andrew Morton <akpm@...ux-foundation.org>, "Liam R. Howlett"
 <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, Lorenzo
 Stoakes <lorenzo.stoakes@...cle.com>, Shuah Khan <shuah@...nel.org>,
 Christoph Hellwig <hch@...radead.org>, Michal Hocko <mhocko@...e.com>,
 "Kirill A. Shutemov" <kirill@...temov.name>, Chris Torek
 <chris.torek@...il.com>, linux-arch@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
 linux-snps-arc@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-csky@...r.kernel.org, loongarch@...ts.linux.dev,
 linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
 linux-sh@...r.kernel.org, sparclinux@...r.kernel.org, linux-mm@...ck.org,
 linux-kselftest@...r.kernel.org, linux-abi-devel@...ts.sourceforge.net
Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to
 47 bits

Charlie Jenkins <charlie@...osinc.com> writes:
> On Wed, Sep 11, 2024 at 11:38:55PM +1000, Michael Ellerman wrote:
>> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
>> > Hi Christophe,
>> >
>> > On Tue, Sep 10, 2024 at 11:21 AM Christophe Leroy
>> > <christophe.leroy@...roup.eu> wrote:
>> >> >>> diff --git a/include/uapi/linux/personality.h b/include/uapi/linux/personality.h
>> >> >>> index 49796b7756af..cd3b8c154d9b 100644
>> >> >>> --- a/include/uapi/linux/personality.h
>> >> >>> +++ b/include/uapi/linux/personality.h
>> >> >>> @@ -22,6 +22,7 @@ enum {
>> >> >>>     WHOLE_SECONDS =         0x2000000,
>> >> >>>     STICKY_TIMEOUTS =       0x4000000,
>> >> >>>     ADDR_LIMIT_3GB =        0x8000000,
>> >> >>> +   ADDR_LIMIT_47BIT =      0x10000000,
>> >> >>>   };
>> >> >>
>> >> >> I wonder if ADDR_LIMIT_128T would be clearer?
>> >> >>
>> >> >
>> >> > I don't follow, what does 128T represent?
>> >>
>> >> 128T is 128 Terabytes, that's the maximum size achievable with a 47BIT
>> >> address, that naming would be more consistant with the ADDR_LIMIT_3GB
>> >> just above that means a 3 Gigabytes limit.
>> >
>> > Hence ADDR_LIMIT_128TB?
>> 
>> Yes it should be 128TB. Typo by me.
>
> 47BIT was selected because the usecase for this flag is for applications
> that want to store data in the upper bits of a virtual address space. In
> this case, how large the virtual address space is irrelevant, and only
> the number of bits that are being used, and hence the number of bits
> that are free.

Yeah I understand that's how you came to the problem.

But for the user API I think using the size of the address space is
clearer, easier to explain, and matches the existing ADDR_LIMIT_3GB.

cheers