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 for Android: free password hash cracker in your pocket

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

Message-ID: <Zof_Q27WLYu-b1Sc@archie.me>
Date: Fri, 5 Jul 2024 21:12:19 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Theodore Ts'o <tytso@....edu>, David Polakovic <email@...lakovic.space>
Cc: Alexander Lobakin <aleksander.lobakin@...el.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 Thu, Jul 04, 2024 at 01:49:17PM -0400, Theodore Ts'o wrote:
> 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.

tl;dr: Documentation/process/submitting-patches.rst.

> 
> 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.

That was what I thought when I first read this thread (good CS principle
but questionable from engineering perspective).

> 
> 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.

Oh, I missed that "DIY" nature.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)