public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	"carlos@redhat.com" <carlos@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	x86@kernel.org, paulmck <paulmck@kernel.org>,
	Michael Jeanson <mjeanson@efficios.com>
Subject: Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen
Date: Fri, 10 Jan 2025 14:16:54 -0500	[thread overview]
Message-ID: <2c625f72-ed5d-4426-abd9-5d80bfe40694@efficios.com> (raw)
In-Reply-To: <87cygutvds.fsf@oldenburg.str.redhat.com>

On 2025-01-10 12:46, Florian Weimer wrote:
> * Mathieu Desnoyers:
> 
>> On 2025-01-10 12:10, Florian Weimer wrote:
>>> * Mathieu Desnoyers:
>>>
>>>> On 2025-01-10 11:54, Peter Zijlstra wrote:
>>>>> On Fri, Jan 10, 2025 at 10:55:36AM -0500, 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.
>>>>> What is the exact race? Should not munmap() invalidate the TLBs
>>>>> before
>>>>> it allows overlapping mmap() to complete?
>>>>
>>>> The race Mark mentioned (on ARM) is AFAIU the following scenario:
>>>>
>>>> CPU 0                     CPU 1
>>>>
>>>> - dlopen()
>>>>     - mmap PROT_EXEC @addr
>>>>                             - fetch insn @addr, CPU state expects unchanged insn.
>>>>                             - execute unrelated code
>>>> - dlclose(addr)
>>>>     - munmap @addr
>>>> - dlopen()
>>>>     - mmap PROT_EXEC @addr
>>>>                             - fetch new insn @addr. Incoherent CPU state.
>>> Unmapping an object while code is executing in it is undefined.
>>
>> That's not the scenario though. In this scenario, CPU 1 executes
>> _unrelated code_ while we unmap @addr.
> 
> Oh, so CPU 1 initially executes some code, returns to some safe,
> persistent code (“the execute unrelated code” part), this code
> synchronizes with the dlclose and the dlopen that execute on CPU 0,
> obtains a pointer to some supposedly safely published function in the
> newly mapped object, and calls it.  And that fails because previously
> cached information about the code is invalid?

Correct.

> 
> Additional awkwardness may result if the initial execution is
> speculative, and the code on CPU 1 only synchronizes with the dlopen,
> and not the previous dlclose because it does not know about it at all?

I'm not sure I follow this last example. Can you explain further what
you have in mind ?

Thanks,

Mathieu

> 
> Thanks,
> Florian
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com


  reply	other threads:[~2025-01-10 19:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 15:55 Prevent inconsistent CPU state after sequence of dlclose/dlopen Mathieu Desnoyers
2025-01-10 16:47 ` Adhemerval Zanella Netto
2025-01-15 20:16   ` Mathieu Desnoyers
2025-01-10 16:54 ` Peter Zijlstra
2025-01-10 17:02   ` Mathieu Desnoyers
2025-01-10 17:10     ` Florian Weimer
2025-01-10 17:14       ` Adhemerval Zanella Netto
2025-01-10 17:15       ` Mathieu Desnoyers
2025-01-10 17:24         ` Adhemerval Zanella Netto
2025-01-10 17:35           ` Mathieu Desnoyers
2025-01-10 17:46         ` Florian Weimer
2025-01-10 19:16           ` Mathieu Desnoyers [this message]
2025-01-10 17:11     ` Peter Zijlstra
2025-01-10 18:41       ` Mark Rutland
2025-01-10 17:12     ` Adhemerval Zanella Netto
2025-01-10 17:04 ` Florian Weimer
2025-01-10 17:13   ` Mathieu Desnoyers
2025-01-10 18:33     ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c625f72-ed5d-4426-abd9-5d80bfe40694@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mjeanson@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox