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: <20240704174917.GB973460@mit.edu>
Date: Thu, 4 Jul 2024 13:49:17 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: David Polakovic <email@...lakovic.space>
Cc: Alexander Lobakin <aleksander.lobakin@...el.com>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        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 Wed, Jul 03, 2024 at 05:29:58PM +0200, David Polakovic wrote:
> 
> 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.

You state that you're not experienced enough to be able to send "a
merge request".  Fair enough; you also apparently don't know that
github merges is not how kernel patches are submitted, reviewed, and
integrated.

What you apparently don't appreciate it is that performance is
something that is critically important for the Linux kernel, and using
multiple precision integers is not really compatible with the best and
highest performance.  Computer Science is an engineering discipline,
and it's all about tradeoffs.  You could enginere a plane that can
travel faster than the speed of sound, but if that compromises fuel
efficiency and annoying people who are below its flight path, pursuing
speed at all costs is not going to lead to commercial success.
(Exhibit 1: The Concorde).

Similarly, trying to make sure that software will work in the year 292
Billion AD might not be all something that most people would consider
high priority.  After all, it's.... unlikely... that the x86_64
architecture will still be what we will be using 290 billion years
from now.  So if we need recompile the kernel sometime in the next 100
billion years for some new CPU architecture, and if it's unlikely that
hard drives brought brand new are likely to be still in operation a
decade or two from now --- there is plenty of time to evolve the
on-disk format before a billion years go by, let alone 100 billion or
200 billion years.

Finally, kernel development is driven by people who are willing to do
the work.  If you want to demonstrate that it's possible to use MP
integer mathematicswithout horribly comprmising performance, then you
need to do the work.  (BTW, if you don't know what the term "cache
line" means, then I encourage that you understand that first.)  But
dropping a pointer to a blog post and expecting that people to do your
homework for you is not really realistic.

Cheers,

					- Ted