From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C917D3E47C; Sun, 7 Apr 2024 13:13:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712495590; cv=none; b=jEUExmqRE2MRPszAjMYuP8qgHQu5UBOAkPUCP1Ffd1iIusai69m+tDKQbx79L/iJqyCWOQinRvxSVjbeLKjPSJMZPjlg7ta1FR0L1lqp1hECJSvH5YLNlDWif9NZN8HCHAxMHpqcdahW9uM0DuLIq+ElBw4YEhZL/sUboaE/+uc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712495590; c=relaxed/simple; bh=9DwqCpxy69q3nEwyB3saBmEBmLmaAle1fIyBv6Te3LA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FN3Xl0XFZzmAzsdg3CEShP4RWOloWvuzVeDL8WsGuMNtfU1jo8VZaMSF7Zpi36Xkbdt+LUNRE79og96Few2+eqpGtOS0wpkvZ6hvRFxq5yIJoIJIBVc4VGa1I/8pmvDpz06q0w9qnfMnyJdspyDHgAgEdv5ZsEV4yPUW7NG/P4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oS3o+YFu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oS3o+YFu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1A80C433B1; Sun, 7 Apr 2024 13:13:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712495590; bh=9DwqCpxy69q3nEwyB3saBmEBmLmaAle1fIyBv6Te3LA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oS3o+YFuB/aywJg7YOWCxEoOcbzfWPvHG3ypLSVCY5E68Vellg+JLkmNk/plNngsx aa8of5XxDVVvFUNDVAEGV7tFyb3Xhum4Na8Ll9NEPd5s1loePQzA+yFc8f0iweoZep RI27nwJfloYm9+BfgugbIilBQkvnBV9ZrCBM9AWEnIZcdWmg3icw1KluS/m/t9xFbc EubqjM+xPe1K3+GHocGR8KSHwdmPDuD/Mxq2KFntxMCXvnchL7XyJcOAcgHTd/laFm W4HEwuK3WuVn0uabk+p61bKGceizlkGvPAYdS1IHqnBGtdcuFgPXWI6vipuklBzQUU 82ASghHFEA/ug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Borislav Petkov (AMD)" , Paul Menzel , Nikolay Borisov , Marco Elver , Masahiro Yamada , Sasha Levin , linux-kbuild@vger.kernel.org Subject: [PATCH AUTOSEL 6.6 22/22] kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries Date: Sun, 7 Apr 2024 09:12:21 -0400 Message-ID: <20240407131231.1051652-22-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240407131231.1051652-1-sashal@kernel.org> References: <20240407131231.1051652-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.6.25 Content-Transfer-Encoding: 8bit From: "Borislav Petkov (AMD)" [ Upstream commit 54babdc0343fff2f32dfaafaaa9e42c4db278204 ] When KCSAN and CONSTRUCTORS are enabled, one can trigger the "Unpatched return thunk in use. This should not happen!" catch-all warning. Usually, when objtool runs on the .o objects, it does generate a section .return_sites which contains all offsets in the objects to the return thunks of the functions present there. Those return thunks then get patched at runtime by the alternatives. KCSAN and CONSTRUCTORS add this to the object file's .text.startup section: ------------------- Disassembly of section .text.startup: ... 0000000000000010 <_sub_I_00099_0>: 10: f3 0f 1e fa endbr64 14: e8 00 00 00 00 call 19 <_sub_I_00099_0+0x9> 15: R_X86_64_PLT32 __tsan_init-0x4 19: e9 00 00 00 00 jmp 1e <__UNIQUE_ID___addressable_cryptd_alloc_aead349+0x6> 1a: R_X86_64_PLT32 __x86_return_thunk-0x4 ------------------- which, if it is built as a module goes through the intermediary stage of creating a .mod.c file which, when translated, receives a second constructor: ------------------- Disassembly of section .text.startup: 0000000000000010 <_sub_I_00099_0>: 10: f3 0f 1e fa endbr64 14: e8 00 00 00 00 call 19 <_sub_I_00099_0+0x9> 15: R_X86_64_PLT32 __tsan_init-0x4 19: e9 00 00 00 00 jmp 1e <_sub_I_00099_0+0xe> 1a: R_X86_64_PLT32 __x86_return_thunk-0x4 ... 0000000000000030 <_sub_I_00099_0>: 30: f3 0f 1e fa endbr64 34: e8 00 00 00 00 call 39 <_sub_I_00099_0+0x9> 35: R_X86_64_PLT32 __tsan_init-0x4 39: e9 00 00 00 00 jmp 3e <__ksymtab_cryptd_alloc_ahash+0x2> 3a: R_X86_64_PLT32 __x86_return_thunk-0x4 ------------------- in the .ko file. Objtool has run already so that second constructor's return thunk cannot be added to the .return_sites section and thus the return thunk remains unpatched and the warning rightfully fires. Drop KCSAN flags from the mod.c generation stage as those constructors do not contain data races one would be interested about. Debugged together with David Kaplan and Nikolay Borisov . Reported-by: Paul Menzel Closes: https://lore.kernel.org/r/0851a207-7143-417e-be31-8bf2b3afb57d@molgen.mpg.de Signed-off-by: Borislav Petkov (AMD) Tested-by: Paul Menzel # Dell XPS 13 Reviewed-by: Nikolay Borisov Reviewed-by: Marco Elver Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin --- scripts/Makefile.modfinal | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal index b3a6aa8fbe8cb..1979913aff682 100644 --- a/scripts/Makefile.modfinal +++ b/scripts/Makefile.modfinal @@ -23,7 +23,7 @@ modname = $(notdir $(@:.mod.o=)) part-of-module = y quiet_cmd_cc_o_c = CC [M] $@ - cmd_cc_o_c = $(CC) $(filter-out $(CC_FLAGS_CFI) $(CFLAGS_GCOV), $(c_flags)) -c -o $@ $< + cmd_cc_o_c = $(CC) $(filter-out $(CC_FLAGS_CFI) $(CFLAGS_GCOV) $(CFLAGS_KCSAN), $(c_flags)) -c -o $@ $< %.mod.o: %.mod.c FORCE $(call if_changed_dep,cc_o_c) -- 2.43.0