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: <d88861a6-ccd9-3fe5-67e0-b50a72ca1e51@dpolakovic.space>
Date: Wed, 3 Jul 2024 17:29:58 +0200
From: David Polakovic <email@...lakovic.space>
To: 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>, "H. Peter Anvin" <hpa@...or.com>,
 Alexander Lobakin <alexandr.lobakin@...el.com>,
 Jakub Kicinski <kuba@...nel.org>
Subject: Re: proposition for fixing Y292B bug

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