From patchwork Tue May 26 18:52:37 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 225392 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFDA5C433E1 for ; Tue, 26 May 2020 19:02:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFC3F208C3 for ; Tue, 26 May 2020 19:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590519773; bh=k35D95v8qmSYVPExxFNvXGV1WmuOz8fXUT0Z2szsg3g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=1dsUyKV7/Lr9EdHknVeZ1YGy0Hd30kdXbGNvAIuZSAjEZzhYSgrQ63em233eSNK5j sBfcvurh8NReXGS5eq6Crse2FqGhoyC5XJZF8sMuLVFcq0348+7X6Hj08JePm2XoUJ /wSBldmAc31oXw2ISz+sEfbaZi4AUnZiqDX2vpuo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403833AbgEZTCv (ORCPT ); Tue, 26 May 2020 15:02:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:57808 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390512AbgEZTCu (ORCPT ); Tue, 26 May 2020 15:02:50 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D8DAD208B3; Tue, 26 May 2020 19:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590519769; bh=k35D95v8qmSYVPExxFNvXGV1WmuOz8fXUT0Z2szsg3g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qfWnK8EM4PLgBxJalnwuVPHVte/tV4ktmB2ICDogyGGJKKYdxkscOO3oFgUi8tJhS o+YW1J+naXRVUWM7za0IuxJOv95d5SIjbG62mpYvzL9UcQmt17JzbRCCtYTNBCunqp jip/9eXagpkttS5rG+UHJhch34xd4o1f4VESIVVw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Andrey Ryabinin , Josh Poimboeuf , Peter Zijlstra , Borislav Petkov , Dmitry Vyukov , Thomas Gleixner , Ingo Molnar , Kees Cook , Matthew Wilcox , Ard Biesheuvel , Andy Shevchenko , Andrew Morton , Linus Torvalds Subject: [PATCH 4.19 02/81] ubsan: build ubsan.c more conservatively Date: Tue, 26 May 2020 20:52:37 +0200 Message-Id: <20200526183923.677631870@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200526183923.108515292@linuxfoundation.org> References: <20200526183923.108515292@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Arnd Bergmann commit af700eaed0564d5d3963a7a51cb0843629d7fe3d upstream. objtool points out several conditions that it does not like, depending on the combination with other configuration options and compiler variants: stack protector: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to __stack_chk_fail() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbe: call to __stack_chk_fail() with UACCESS enabled stackleak plugin: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled kasan: lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x25: call to memcpy() with UACCESS enabled The stackleak and kasan options just need to be disabled for this file as we do for other files already. For the stack protector, we already attempt to disable it, but this fails on clang because the check is mixed with the gcc specific -fno-conserve-stack option. According to Andrey Ryabinin, that option is not even needed, dropping it here fixes the stackprotector issue. Link: http://lkml.kernel.org/r/20190722125139.1335385-1-arnd@arndb.de Link: https://lore.kernel.org/lkml/20190617123109.667090-1-arnd@arndb.de/t/ Link: https://lore.kernel.org/lkml/20190722091050.2188664-1-arnd@arndb.de/t/ Fixes: d08965a27e84 ("x86/uaccess, ubsan: Fix UBSAN vs. SMAP") Signed-off-by: Arnd Bergmann Reviewed-by: Andrey Ryabinin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Dmitry Vyukov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Kees Cook Cc: Matthew Wilcox Cc: Ard Biesheuvel Cc: Andy Shevchenko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- lib/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/lib/Makefile +++ b/lib/Makefile @@ -269,7 +269,8 @@ obj-$(CONFIG_UCS2_STRING) += ucs2_string obj-$(CONFIG_UBSAN) += ubsan.o UBSAN_SANITIZE_ubsan.o := n -CFLAGS_ubsan.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) +KASAN_SANITIZE_ubsan.o := n +CFLAGS_ubsan.o := $(call cc-option, -fno-stack-protector) $(DISABLE_STACKLEAK_PLUGIN) obj-$(CONFIG_SBITMAP) += sbitmap.o