linux-kernel - Re: proposition for fixing Y292B bug

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: <848ADF85-6138-4D56-8DDD-E327B8AFC5EC@zytor.com>
Date: Thu, 04 Jul 2024 19:59:13 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: David Polakovic <email@...lakovic.space>,
        Alexander Lobakin <aleksander.lobakin@...el.com>,
        Bagas Sanjaya <bagasdotme@...il.com>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: proposition for fixing Y292B bug

On July 3, 2024 8:29:58 AM PDT, David Polakovic <email@...lakovic.space> wrote:
>On 7/1/24 15:31, Alexander Lobakin wrote:
>> From: Bagas Sanjaya <bagasdotme@...il.com>
>> Date: Mon, 1 Jul 2024 16:07:48 +0700
>> 
>>> On Sun, Jun 30, 2024 at 05:27:24PM +0200, David Polakovic wrote:
>>>> Thanks for reply.
>>> Please don't top-post on LKML, reply inline with appropriate context
>>> instead.
>>> 
>>>> My proposed solution was to create this BigInt datatype, which
>>>> stores the value in array. The functions for division, multiplication,
>>>> addition, subtraction and comparison could be stored in separate
>>>> ".h" library for manipulation with BigInt datatype. The paper speaks
>>>> more in detail.
>> IRRC there is big integer type somewhere in either lib/ or crypto/,
>> I don't remember exactly. It's used only for crypto tho.
>> 
>>>> And yes, this truly is an userspace solution, but for kernel space
>>>> implementation I have zero to none experience. Therefore I wrote
>>>> here.
>>> There was a proposal for adding 128-bit unsigned integer (see [1]).
>>> The signed counterpart should be analogous.
>> I have generic 128-bit integer API/infra for the kernel in my internal
>> repo. I've been planning to upstream it for a couple years already, but
>> every time couldn't find a slot to do that.
>> I can upload it to my open GitHub, so that maybe someone else who needs
>> it could pick it up?
>> 
>>> Thanks.
>>> 
>>> [1]: https://lore.kernel.org/lkml/20220722145514.767592-1-alexandr.lobakin@intel.com/
>> Thanks,
>> Olek
>
>
>I am not sure if I don't understand your solution, but extending the
>memory designation from 64 to 128 bits, is another temporary
>solution, which will again overflow one day.
>
>The sole reason why I was proposing the new "BigInt" type was to
>store each digit of the time_c as separate element of array, which
>could be resized (added one digit) as needed. The only limit would
>then be the physical amount of memory in the machine.
>
>dpo
>

So now you are worried about the Y5e30 problem?!

You realize that you are now talking the orders of magnitude of time for which: 

"	The estimated time until most or all of the remaining 1–10% of stellar remnants not ejected from galaxies fall into their galaxies' central supermassive black holes. By this point, with binary stars having fallen into each other, and planets into their stars, via emission of gravitational radiation, only solitary objects (stellar remnants, brown dwarfs, ejected planetary-mass objects, black holes) will remain in the universe."

I genuinely thought this whole thread was a practical joke...