linux-kernel - Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen

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: <5de4b3c3-7f11-4d81-ac75-1b7381a87f0a@linaro.org>
Date: Fri, 10 Jan 2025 13:47:23 -0300
From: Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 libc-alpha <libc-alpha@...rceware.org>
Cc: Florian Weimer <fweimer@...hat.com>, "carlos@...hat.com"
 <carlos@...hat.com>, Mark Rutland <mark.rutland@....com>,
 Peter Zijlstra <peterz@...radead.org>,
 linux-kernel <linux-kernel@...r.kernel.org>, x86@...nel.org,
 paulmck <paulmck@...nel.org>, Michael Jeanson <mjeanson@...icios.com>
Subject: Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen



On 10/01/25 12:55, Mathieu Desnoyers wrote:
> Hi,
> 
> I was discussing with Mark Rutland recently, and he pointed out that a
> sequence of dlclose/dlopen mapping new code at the same addresses in
> multithreaded environments is an issue on ARM, and possibly on Intel/AMD
> with the newer TLB broadcast maintenance.
> 
> I maintain the membarrier(2) system call, which provides a
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE command for this
> purpose. It's been there since Linux 4.16. It can be configured
> out (CONFIG_MEMBARRIER=n), but it's enabled by default.
> 
> Calling this after dlclose() in glibc would prevent this issue.
> 
> Is it handled in some other way, or should we open a bugzilla
> entry to track this ?

Yes please, it would be helpful if you can add some information on 
what kind of hardware and kernel version this is an issue.  

Also, could you add some detail of the issue and why kernel itself does
not or can not guarantee memory consistent after the mmap call?

Is is because this would be an extra non-required overhead on
mmap that userland should handle?