linux-kernel - Re: [RFC] tools/memory-model: Rule out OOTA

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: <446d6a64-7ee4-494a-bbfe-dbfdb6959f9c@huaweicloud.com>
Date: Thu, 16 Jan 2025 20:28:06 +0100
From: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To: paulmck@...nel.org
Cc: Alan Stern <stern@...land.harvard.edu>, 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, lkmm@...ts.linux.dev,
 hernan.poncedeleon@...weicloud.com
Subject: Re: [RFC] tools/memory-model: Rule out OOTA

Am 1/16/2025 um 7:40 PM schrieb Paul E. McKenney:
> 	o	If a value is read in the seqlock reader and used
> 		across a "you need to retry" indication, that
> 		flags a seqlock data race.

This too is insufficient, you also need to prevent dereferencing or 
having control dependency inside the seqlock. Otherwise you could 
derefence a torn pointer and...

At this point your definition of data race becomes pretty much the same 
as we have.

https://github.com/open-s4c/libvsync/blob/main/vmm/vmm.cat#L150

(also this rule should only concern reads that are actually "data-racy" 
- if the read is synchronized by some other writes, then you can read & 
use it just fine across the seqlock data race)

I also noticed that in my previous e-mail I had overlooked the reads 
inside the CS in the failure case, but you are of course right, there 
needs to be some mechanism to prevent them from being data racy unless 
abused.

But I am not sure how to formalize that in a way that is simpler than 
just re-defining data races in general, without adding some special 
support to herd7 for it.

What do you think?

   jonas