From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E92B4400 for ; Fri, 10 Jan 2025 17:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736531183; cv=none; b=mwmnVMeklR1dyixfl/13OvtciPlIaSyHsFr/XOtixXM58LBXuneX7JkvRmeuMfwmjUhvyWQk15eqgFzudgs0m17I8LFLh0hJDWmYFB2le4iuap0VW5cg5bk5fhPx6t04tS6ZlPozqm1/CMSwec4JkZP1wFtKbGS6gLEv2mVzjeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736531183; c=relaxed/simple; bh=3O3eGf3fJDCllBgrO+FV2NuR0BTmuOlWjpWSGW67794=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qNzjMO5YZJVY902ElXtEDM9CpM6SX+KuJoRGP7mdVWTyb3OxW3cHIuhQFP9uk5DCEhmR3FIrJ+3NB77k4Qx7hoF+vouzOZiaD5dPMhBI4AL1THjAAFyEkLeKcF8i+V9BVl2/CrHkHM5lZ1vcIYpAI8lxt2sM4qbgHu64bxApmiA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ai649H7A; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ai649H7A" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736531180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dUnrNoXSq3Aq7N2DMoD+SMBEhh6k94IJZiifIiOZ6yE=; b=Ai649H7ACha4+7Tejy/Ri5tSRkCL3YiRtEKkMJUX5Hi5obGSBh/TyWeUIPGjkQXrjENE5U zXt3NsWXx8rQz/GW1BhjTzVNuFnIG1R3rxaiBb9ux6D53HkaFMA/zxdSBgcXxuQJS44EcY 4UPS7zwyiiDE8OFH6X2WWX45N1Dg36M= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-484-bDJFdrv5PLaKQr8eCWvaWQ-1; Fri, 10 Jan 2025 12:46:17 -0500 X-MC-Unique: bDJFdrv5PLaKQr8eCWvaWQ-1 X-Mimecast-MFC-AGG-ID: bDJFdrv5PLaKQr8eCWvaWQ Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 021F31956055; Fri, 10 Jan 2025 17:46:15 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.2]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C8DDC30001BE; Fri, 10 Jan 2025 17:46:10 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Peter Zijlstra , "libc-alpha@sourceware.org" , "carlos@redhat.com" , Mark Rutland , linux-kernel , x86@kernel.org, paulmck , Michael Jeanson Subject: Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen In-Reply-To: (Mathieu Desnoyers's message of "Fri, 10 Jan 2025 12:15:20 -0500") References: <20250110165412.GC4213@noisy.programming.kicks-ass.net> <8c1ad304-61bb-4bdf-aa75-8633f3d0196c@efficios.com> <87ldvitx0t.fsf@oldenburg.str.redhat.com> Date: Fri, 10 Jan 2025 18:46:07 +0100 Message-ID: <87cygutvds.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 * Mathieu Desnoyers: > On 2025-01-10 12:10, Florian Weimer wrote: >> * Mathieu Desnoyers: >>=20 >>> 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 unchan= ged 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 (=E2=80=9Cthe execute unrelated code=E2=80=9D part), this c= ode 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? 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? Thanks, Florian