Message ID | 20230915-uml-kasan-v2-1-ef3f3ff4f144@axis.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp868095vqi; Fri, 15 Sep 2023 00:32:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFC8iprw/gAf2RGz9rlRlwtWj/jqvQyHOZh2z6rjQ96Ax5iSdV1Z5BOXXsxGA9PCFxTyRwu X-Received: by 2002:a17:902:e5cb:b0:1c1:e7b2:27ad with SMTP id u11-20020a170902e5cb00b001c1e7b227admr760881plf.60.1694763174277; Fri, 15 Sep 2023 00:32:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694763174; cv=none; d=google.com; s=arc-20160816; b=LbMjjzro5ReCqLFe9fCAUWBONCO6IzaQoelNxTGNVv6FzvCM3+EDLA9r65+sc9H3n3 tzaXJi/b89MCDRpIGKXL7iqE+8cXKQlToEfvSydGNP+foE+e4NStleMbbp+hhlQUeDbI 945xi1FRSyIWazA0qRKDgi/y8YDu04we9AypTvro2fbotYwu4DUJqkNrWt5q0ZDHZo35 x7cpTJDoVRNg374bm5kaHuH3YvThMM45iTP99ch7FASH4IwoMG8LnXYBvTP1saX06Msg kPIahY6HIRxoQ83AjZR064/1ue4xszgRK3mvFqFnbOK0GuUzcDakohDCq5ARv5zji5Rt bKyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=ZtQJD7Nx7MRDe9gv5VcJ0bJ+FN+0txe0L0UuBp9Hx9U=; fh=/BsWuqvqe3eo0r5JRt58YrKg2sVLpkLk+6gUJtF4R30=; b=cXw+EY2DKthg4IJCtwHovWkVRu/VxA9qB2z1LfhnZMq569LYDD0Jw9HlPtaQtOD8sr 5LfuDU2HyFbOylW+Ow1uTH7fWxuZINYvEAHoKWSBy6g527I6H6IGqB1elsBJNUA+ILSp IT7mgov9iZQtITghblk6nDQYQ4NIR2tFvAz/ucF+Fj0SkGsB4y1wURKrxNz5gZbkKdLa Ffi+w928HqNVHNIpvjRLKad0oz1EfFIV7zATMWQvDa2IMdtiQSo7GZXCiXSOaQs2weB2 je+d3DeOsoYFskSRiIjTXeQHPpNynhzg2To+ilnzzUT4RNlqxK5FOJarNDnJmMXepNRK La3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=mNAug2cJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id cp2-20020a170902e78200b001b7e19195b7si2924360plb.29.2023.09.15.00.32.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 00:32:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=mNAug2cJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 26A26831E2A9; Fri, 15 Sep 2023 00:30:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232487AbjIOHaO (ORCPT <rfc822;pwkd43@gmail.com> + 33 others); Fri, 15 Sep 2023 03:30:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229767AbjIOHaK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 15 Sep 2023 03:30:10 -0400 Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A354F1724 for <linux-kernel@vger.kernel.org>; Fri, 15 Sep 2023 00:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1694762998; x=1726298998; h=from:date:subject:mime-version:content-transfer-encoding: message-id:to:cc; bh=ZtQJD7Nx7MRDe9gv5VcJ0bJ+FN+0txe0L0UuBp9Hx9U=; b=mNAug2cJoD8yAgtTgaQu1OxFfQYSn1HgocrqO7Je9uekG9jmyjP3l/GS U884HDcbY5daRcUNQ79eZSOQwXEAoC28EeenGNR1EVnzEriR4NgtPQWJN SXS+bGScbxiY+5xiHQYOA6SSHIFvS41ho2U2NpH9IReuxRasYPNDNBn5r +NCc9IICKe+pCSWJxo5dsP6Zw4QIQqkYdLPhuXV0lOB5ZzDlYvcWCEsEh mskNnUaqhgdkc9VJz7sAyMlK6FPzsID7Au/Vniz7GTZ0Hy0eTr6iXOXhK 7GqiYYywu719Bt+xde/e6RSJ8BKtHXK/11K73dRk2Fn9tUKiK4i9RhHpF g==; From: Vincent Whitchurch <vincent.whitchurch@axis.com> Date: Fri, 15 Sep 2023 09:29:52 +0200 Subject: [PATCH v2] x86: Fix build of UML with KASAN MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <20230915-uml-kasan-v2-1-ef3f3ff4f144@axis.com> X-B4-Tracking: v=1; b=H4sIAO8HBGUC/22Nyw6CMBBFf4XM2jGlgAFX/odhMfQhE7U1HSUYw r9bWLs8J/exgLjETuBcLJDcxMIxZNCHAsxI4eaQbWbQSlfqpDr8PB94J6GAuuq0tbWp2qaFnB9 IHA6Jghm3ho9Rb/qVnOd5v7j2mUeWd0zf/XEqN/tvfCqxxMaTaW2tOlv7C80sRxOf0K/r+gOhX iW1uAAAAA== To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, Frederic Weisbecker <frederic@kernel.org>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Peter Zijlstra <peterz@infradead.org> CC: Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, <linux-um@lists.infradead.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Alexander Potapenko <glider@google.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, <kasan-dev@googlegroups.com>, <linux-kernel@vger.kernel.org>, <kernel@axis.com>, Vincent Whitchurch <vincent.whitchurch@axis.com> X-Mailer: b4 0.12.3 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 15 Sep 2023 00:30:24 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777087989884917189 X-GMAIL-MSGID: 1777087989884917189 |
Series |
[v2] x86: Fix build of UML with KASAN
|
|
Commit Message
Vincent Whitchurch
Sept. 15, 2023, 7:29 a.m. UTC
Building UML with KASAN fails since commit 69d4c0d32186 ("entry, kasan,
x86: Disallow overriding mem*() functions") with the following errors:
$ tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y
...
ld: mm/kasan/shadow.o: in function `memset':
shadow.c:(.text+0x40): multiple definition of `memset';
arch/x86/lib/memset_64.o:(.noinstr.text+0x0): first defined here
ld: mm/kasan/shadow.o: in function `memmove':
shadow.c:(.text+0x90): multiple definition of `memmove';
arch/x86/lib/memmove_64.o:(.noinstr.text+0x0): first defined here
ld: mm/kasan/shadow.o: in function `memcpy':
shadow.c:(.text+0x110): multiple definition of `memcpy';
arch/x86/lib/memcpy_64.o:(.noinstr.text+0x0): first defined here
UML does not use GENERIC_ENTRY and is still supposed to be allowed to
override the mem*() functions, so use weak aliases in that case.
Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
Changes in v2:
- Use CONFIG_UML instead of CONFIG_GENERIC_ENTRY.
- Link to v1: https://lore.kernel.org/r/20230609-uml-kasan-v1-1-5fac8d409d4f@axis.com
---
arch/x86/lib/memcpy_64.S | 4 ++++
arch/x86/lib/memmove_64.S | 4 ++++
arch/x86/lib/memset_64.S | 4 ++++
3 files changed, 12 insertions(+)
---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20230609-uml-kasan-2392dd4c3858
Best regards,
Comments
* Vincent Whitchurch <vincent.whitchurch@axis.com> wrote: > Building UML with KASAN fails since commit 69d4c0d32186 ("entry, kasan, > x86: Disallow overriding mem*() functions") with the following errors: > > $ tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y > ... > ld: mm/kasan/shadow.o: in function `memset': > shadow.c:(.text+0x40): multiple definition of `memset'; > arch/x86/lib/memset_64.o:(.noinstr.text+0x0): first defined here > ld: mm/kasan/shadow.o: in function `memmove': > shadow.c:(.text+0x90): multiple definition of `memmove'; > arch/x86/lib/memmove_64.o:(.noinstr.text+0x0): first defined here > ld: mm/kasan/shadow.o: in function `memcpy': > shadow.c:(.text+0x110): multiple definition of `memcpy'; > arch/x86/lib/memcpy_64.o:(.noinstr.text+0x0): first defined here So the breakage was ~9 months ago, and apparently nobody build-tested UML? Does UML boot with the fix? > UML does not use GENERIC_ENTRY and is still supposed to be allowed to > override the mem*() functions, so use weak aliases in that case. > > Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions") > Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> > --- > Changes in v2: > - Use CONFIG_UML instead of CONFIG_GENERIC_ENTRY. > - Link to v1: https://lore.kernel.org/r/20230609-uml-kasan-v1-1-5fac8d409d4f@axis.com > --- > arch/x86/lib/memcpy_64.S | 4 ++++ > arch/x86/lib/memmove_64.S | 4 ++++ > arch/x86/lib/memset_64.S | 4 ++++ > 3 files changed, 12 insertions(+) > > diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S > index 8f95fb267caa..47b004851cf3 100644 > --- a/arch/x86/lib/memcpy_64.S > +++ b/arch/x86/lib/memcpy_64.S > @@ -40,7 +40,11 @@ SYM_TYPED_FUNC_START(__memcpy) > SYM_FUNC_END(__memcpy) > EXPORT_SYMBOL(__memcpy) > > +#ifdef CONFIG_UML > +SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy) > +#else > SYM_FUNC_ALIAS(memcpy, __memcpy) > +#endif > EXPORT_SYMBOL(memcpy) Meh, the extra 3 #ifdefs are rather ugly and don't really express UML's expectations here. So how about introducing a SYM_FUNC_ALIAS_MEMFUNC() variant on x86 in a suitable header, which maps to the right thing, with a comment added that explains that this is for UML's mem*() functions? Thanks, Ingo
On Fri, 2023-09-15 at 11:32 +0200, Ingo Molnar wrote: > > > ld: mm/kasan/shadow.o: in function `memset': > > shadow.c:(.text+0x40): multiple definition of `memset'; > > arch/x86/lib/memset_64.o:(.noinstr.text+0x0): first defined here > > ld: mm/kasan/shadow.o: in function `memmove': > > shadow.c:(.text+0x90): multiple definition of `memmove'; > > arch/x86/lib/memmove_64.o:(.noinstr.text+0x0): first defined here > > ld: mm/kasan/shadow.o: in function `memcpy': > > shadow.c:(.text+0x110): multiple definition of `memcpy'; > > arch/x86/lib/memcpy_64.o:(.noinstr.text+0x0): first defined here > > So the breakage was ~9 months ago, and apparently nobody build-tested UML? Well, first of all, it's only with KASAN, and then I think we probably all did and applied a similar fix or this one ... I have a in my tree that simplies marks the three symbols as weak again, for instance, dating back to March 27th. Didn't publish it at the time, it probably got lost in the shuffle, don't remember. Also, a variant of this patch has been around for three months too. > Does UML boot with the fix? Sure, works fine as long as the symbols are marked weak _somehow_. johannes
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S index 8f95fb267caa..47b004851cf3 100644 --- a/arch/x86/lib/memcpy_64.S +++ b/arch/x86/lib/memcpy_64.S @@ -40,7 +40,11 @@ SYM_TYPED_FUNC_START(__memcpy) SYM_FUNC_END(__memcpy) EXPORT_SYMBOL(__memcpy) +#ifdef CONFIG_UML +SYM_FUNC_ALIAS_WEAK(memcpy, __memcpy) +#else SYM_FUNC_ALIAS(memcpy, __memcpy) +#endif EXPORT_SYMBOL(memcpy) SYM_FUNC_START_LOCAL(memcpy_orig) diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S index 0559b206fb11..e3a76d38c278 100644 --- a/arch/x86/lib/memmove_64.S +++ b/arch/x86/lib/memmove_64.S @@ -212,5 +212,9 @@ SYM_FUNC_START(__memmove) SYM_FUNC_END(__memmove) EXPORT_SYMBOL(__memmove) +#ifdef CONFIG_UML +SYM_FUNC_ALIAS_WEAK(memmove, __memmove) +#else SYM_FUNC_ALIAS(memmove, __memmove) +#endif EXPORT_SYMBOL(memmove) diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S index 7c59a704c458..6d1c247c821c 100644 --- a/arch/x86/lib/memset_64.S +++ b/arch/x86/lib/memset_64.S @@ -40,7 +40,11 @@ SYM_FUNC_START(__memset) SYM_FUNC_END(__memset) EXPORT_SYMBOL(__memset) +#ifdef CONFIG_UML +SYM_FUNC_ALIAS_WEAK(memset, __memset) +#else SYM_FUNC_ALIAS(memset, __memset) +#endif EXPORT_SYMBOL(memset) SYM_FUNC_START_LOCAL(memset_orig)