linux-kernel - Re: [PATCHv2 0/4] tools/memory-model: Define more of LKMM in tools/memory-model

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: <cb49624b-ae79-4ba5-b550-f73962317032@huaweicloud.com>
Date: Mon, 10 Jun 2024 11:08:54 +0200
From: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: paulmck@...nel.org, parri.andrea@...il.com, will@...nel.org,
 peterz@...radead.org, boqun.feng@...il.com, npiggin@...il.com,
 dhowells@...hat.com, j.alglave@....ac.uk, luc.maranget@...ia.fr,
 akiyks@...il.com, dlustig@...dia.com, joel@...lfernandes.org,
 urezki@...il.com, quic_neeraju@...cinc.com, frederic@...nel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 0/4] tools/memory-model: Define more of LKMM in
 tools/memory-model



Am 6/8/2024 um 3:00 AM schrieb Alan Stern:
> On Wed, Jun 05, 2024 at 09:58:42PM +0200, Jonas Oberhauser wrote:
>>
>>
>> Am 6/4/2024 um 7:56 PM schrieb Alan Stern:
>>> Just to clarify: Your first step encompasses patches 1 - 3, and the
>>> second step is patch 4.  The first three patches can be applied now, but
>>> the last one needs to wait until herd7 has been updated.  Is this all
>>> correct?
>>
>> Exactly.
> 
> With regard to patch 4, how much thought have you and Hernan given to
> backward compatibility?  Once herd7 is changed, old memory model files
> will no longer work correctly.

Yes, Akira pointed this out too.

My thought back then was to update herd now, and wait with the fourth 
patch for a while until most people who run the LKMM would have 
upgraded. However...

> To avoid being so disruptive, perhaps the changes to herd7 should be
> under control of a new command-line or config-file switch.  If the
> switch is enabled, the new simplified code gets used; otherwise herd7
> would continue to use its old built-in rules for special tags
... I like that idea a lot better actually. I think it needs to be 
placed into the files, or people will get strange, silent results.

But then I think we need to make sure that there's no internal behaviors 
left. I don't want to introduce more flags in the future to turn off 
other internal behavior.

jonas