linux-kernel - Re: [PATCH -next] ipc/sem: prevent queue.status tearing in semop

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: <20180720182534.2u2fh5i2cyhd7owo@linux-r8p5>
Date:   Fri, 20 Jul 2018 11:25:34 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Manfred Spraul <manfred@...orfullife.com>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH -next] ipc/sem: prevent queue.status tearing in semop

On Wed, 18 Jul 2018, Manfred Spraul wrote:

>Hello Davidlohr,
>
>On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
>>In order for load/store tearing to work, _all_ accesses to
>>the variable in question need to be done around READ and
>>WRITE_ONCE() macros. Ensure everyone does so for q->status
>>variable for semtimedop().
>What is the background of the above rule?

The fact that it's done under the ipc lock, doesn't mean that
the compiler won't try to get smart. If we have lockless accesses
we musn't see partial stores/loads.

>
>sma->use_global_lock is sometimes used with smp_load_acquire(), 
>sometimes without.
>So far, I assumed that this is safe.
>
>The same applies for nf_conntrack_locks_all, in nf_conntrack_all_lock()

Oh, yeah I remember _that_ saga. I'll have a look but iirc it
seemd ok back then.

Thanks,
Davidlohr