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: <cef39a6f-426d-4c4d-950e-edbbe5e95acf@intel.com>
Date: Mon, 1 Jul 2024 15:31:31 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Bagas Sanjaya <bagasdotme@...il.com>
CC: David Polakovic <email@...lakovic.space>, 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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ