Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3034268imu; Sun, 13 Jan 2019 16:48:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN7kzL/UX5iZmNb5FBgdZrnZUQX/7Q+6TFccQeKrgQAZrWLP/+3FT8SkAszTg9W6SFo26E/t X-Received: by 2002:a63:ff62:: with SMTP id s34mr21222938pgk.325.1547426888825; Sun, 13 Jan 2019 16:48:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547426888; cv=none; d=google.com; s=arc-20160816; b=JTtwiOt9BLCc4c8QfA7Z15b1ZVnEMeiAjeahu4elUbvwUB40+tXdd4cGtTPqWWl4vN Ek0fGOJPj1ao6uHhFfsAR+HBXtEO/labHxUe70t6zoefNidVJsTLVO73iZ9NGkWX53T1 vL+teWLN022VVDjWIzLIbv216h74jEkdoTva4QtAlEY4TlCunF6ItGDSQC2Dj3ufo8K+ vcNJSOwW/+1yrP4hKB98pqlOCE6UMmx+8Y4XrDMZms45Q1mSZtpy2RAqRto1lPpwPSvk Y+4NC/LNlNWrwmd/lgAw/VwbBCxceiu4ZQSA7Tlr65ChRXNLaVIAlqy2WGGFSnKCQHm9 zNkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=GPSA4alIfUBq0OYwlR+6iMmiyibXCTrFkt+6Orf4tWA=; b=lSN9F1MrYZcBwvKMSjDuRpCB5sNBygNEWplKL7mwvHEAc9WCbvSvcofJB+25ii7Wgt QOR6JJHUSHJPmW7RRqcWfP3d2XO5BNSAXQg+b3z6LBf/+huw5CQxkaLIENBnlZ5uhiuE 9Sx32yaaJ8M70k0O87DEDFNsTQCBrkcr4X97dyaVf5+08TPd9rXbcpbvZcQeYtiIaeYE PyWSG/tAZbNMzHwy/OL0e16bOrK5dGDu6F0QORA24EkuWHSMTgrXpig4T8a1ioHfeWVm yJc/qE7XZqEnj1qt0Zaq4auFKuvgJS1xyKOVGQ8Srk2M9tUqDZ2B/BapYQ8oMdsaDySV X//w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si3652831pfn.259.2019.01.13.16.47.52; Sun, 13 Jan 2019 16:48:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726645AbfANAqq (ORCPT + 99 others); Sun, 13 Jan 2019 19:46:46 -0500 Received: from ozlabs.org ([203.11.71.1]:58545 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726617AbfANAqp (ORCPT ); Sun, 13 Jan 2019 19:46:45 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43dFCj0lVQz9s1l; Mon, 14 Jan 2019 11:46:40 +1100 (AEDT) From: Michael Ellerman To: Samuel Holland , Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Masahiro Yamada Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "Jason A. Donenfeld" , Alexey Kardashevskiy Subject: Re: [PATCH v5 1/2] powerpc/32: add stack protector support In-Reply-To: References: <8e81b0647fea15e533a73ad4e9063c059fdfc6df.1537987712.git.christophe.leroy@c-s.fr> Date: Mon, 14 Jan 2019 11:46:40 +1100 Message-ID: <87k1j8dq1b.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Samuel Holland writes: > Hello all, > > On 09/27/18 02:05, Christophe Leroy wrote: > [..snip..] >> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile >> index 07d9dce7eda6..45b8eb4d8fe7 100644 >> --- a/arch/powerpc/Makefile >> +++ b/arch/powerpc/Makefile >> @@ -112,6 +112,9 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION) >> KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET) >> endif >> >> +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard=tls >> +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-reg=r2 >> + >> LDFLAGS_vmlinux-y := -Bstatic >> LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie >> LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y) >> @@ -404,6 +407,13 @@ archclean: >> >> archprepare: checkbin >> >> +ifdef CONFIG_STACKPROTECTOR >> +prepare: stack_protector_prepare >> + >> +stack_protector_prepare: prepare0 >> + $(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk '{if ($$2 == "TASK_CANARY") print $$3;}' include/generated/asm-offsets.h)) >> +endif >> + > > This breaks when building out-of-tree kernel modules. GCC is not getting passed > the -mstack-protector-guard-offset argument, so the default offset is used. The > kernel then panics the first time a function with stack protector is called. > > I'm seeing this on powerpc64. It looks like it was reported for powerpc on > kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201891 Thanks for the bug report. Alexey also hit this and sent an RFC fix. https://patchwork.ozlabs.org/patch/1022751/ But Masahiro thought we could do something less hacky, and hopefully he can help us come up with something better. cheers