From patchwork Wed Oct 4 16:22:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9985173 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 714D260291 for ; Wed, 4 Oct 2017 16:22:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63F4528B51 for ; Wed, 4 Oct 2017 16:22:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5880128B5E; Wed, 4 Oct 2017 16:22:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id A42C928B51 for ; Wed, 4 Oct 2017 16:22:41 +0000 (UTC) Received: (qmail 32519 invoked by uid 550); 4 Oct 2017 16:22:39 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 32495 invoked from network); 4 Oct 2017 16:22:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=luL/eZEpJRJNn4vF86Qx5oqu4LY+9PYJLJkGJDlWJHU=; b=tzvOXSEm69g7L1YCt2ZQ0fxwxWvXcX2GNkSeKBnFCYGHYfVuY33Wirg3S4IKWFHXKp Nya/s3vJtGM7ZheD821PQFVsTrLZuHpE7md5EUfcjSMzT2u30OzSwfudrOg74pU8seem w5Zbrv9G8CRBTU+CnhxeOIE4pXoqZup23sf/aXf/lIwqFiQZfIGgWSyqvUy//DS5xyRc c6xMwZ7VBs4QZlaDPjWXl68LdT/z3FyOjtXiV+nJW9hEdLn7rXlJI1CIp/Blv+oAmgn0 W5tpNDBbq3pUATAIeBWslUKhPJyRxxiONUJdSd/pfVyZCzAR3t32QthMwVZvq4UQTLfk FgoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=luL/eZEpJRJNn4vF86Qx5oqu4LY+9PYJLJkGJDlWJHU=; b=IfGLjo7Kq+z4igQIP3uWNhSdzIzGDh2wV6n1Uwr1wq88BGxc0cjrHwCLKA24XAWedl a776n1Ft/RPOcRTmhoY/ZfudNPWBB6AIHpkcgNocAKcbnSIK8Ky7Ud4RVenY7LlPHgcT F/rXP/wq6ElK2jLUxfQiRcCrqif8FtefGtMoc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=luL/eZEpJRJNn4vF86Qx5oqu4LY+9PYJLJkGJDlWJHU=; b=eTzusd6KvhxtYIYd/7rgSsL9XfHQM9iMuWIsPZU2Avb/Iy8P2ZqsgRImtVUMdqrkBT SjmbBS/9FEWMiCGUUAbGX79CYS+9FfhRasB2eeJK/HIaI7pMfJHEAGcB9M4JXjyS4B3Z fUWTvzAPbw3F+R83aXyxD3jgDQqsGIR6/b1HpMhapwt0DJdsnwyZJAVQkVtfm99+XESJ 6UZPNuIYUxqeiyG1difm0Qvga9R27hSowXWueB/S6Ex/MPaUYW9q+VMOL2NZcIxA+roy 0HJWMS8ziDL6Xm7WLoqfRMphm3wUThHHQxTL2vTubOhV5IRyuU9EAQlcbkIdIH1IIefj dqVg== X-Gm-Message-State: AMCzsaU/lNdFNRIIHRYJlKL4zh1wos0yZm4eVuNktqGYVZpJRY8UeVHY GR36cWW9ArAGhWK1qdTAQ0i5G3/tIRD5RA2dabOJYA== X-Google-Smtp-Source: AOwi7QDpfPG6cMY9pbkyVpWFGEvPB0oTB6WozfQ2EbscS829xmCdAmFO3TU2PBgb1xU8CUt8CMw+BApTXeKMCQEJkg4= X-Received: by 10.36.12.14 with SMTP id 14mr8039817itn.94.1507134145319; Wed, 04 Oct 2017 09:22:25 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <20171004151312.GA20938@kroah.com> References: <1506972007-80614-1-git-send-email-keescook@chromium.org> <1506972007-80614-3-git-send-email-keescook@chromium.org> <20171004151312.GA20938@kroah.com> From: Kees Cook Date: Wed, 4 Oct 2017 09:22:24 -0700 X-Google-Sender-Auth: KrIVrIkbWtyK3xzdfKOpU3pQy2c Message-ID: To: Greg KH Cc: Masahiro Yamada , Andrew Morton , Michal Marek , Ingo Molnar , Laura Abbott , Nicholas Piggin , Al Viro , Linux Kbuild mailing list , Yoshinori Sato , Rich Felker , "David S. Miller" , Linux Kernel Mailing List , linux-sh , "kernel-hardening@lists.openwall.com" , Mark Rutland Subject: Re: [kernel-hardening] Re: [PATCH 2/3] Makefile: Move stackprotector availability out of Kconfig X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Oct 4, 2017 at 8:13 AM, Greg KH wrote: > On Wed, Oct 04, 2017 at 11:33:38PM +0900, Masahiro Yamada wrote: >> Hi Kees, >> >> >> 2017-10-03 4:20 GMT+09:00 Kees Cook : >> > Various portions of the kernel, especially per-architecture pieces, >> > need to know if the compiler is building it with the stack protector. >> > This was done in the arch/Kconfig with 'select', but this doesn't >> > allow a way to do auto-detected compiler support. In preparation for >> > creating an on-if-available default, move the logic for the definition of >> > CONFIG_CC_STACKPROTECTOR into the Makefile. >> > >> > Cc: Masahiro Yamada >> > Cc: Michal Marek >> > Cc: Andrew Morton >> > Cc: Ingo Molnar >> > Cc: Laura Abbott >> > Cc: Nicholas Piggin >> > Cc: Al Viro >> > Cc: linux-kbuild@vger.kernel.org >> > Signed-off-by: Kees Cook >> > --- >> > Makefile | 7 +++++-- >> > arch/Kconfig | 8 -------- >> > 2 files changed, 5 insertions(+), 10 deletions(-) >> > >> > diff --git a/Makefile b/Makefile >> > index d1119941261c..e122a9cf0399 100644 >> > --- a/Makefile >> > +++ b/Makefile >> > @@ -688,8 +688,11 @@ else >> > stackp-flag := $(call cc-option, -fno-stack-protector) >> > endif >> > endif >> > -# Find arch-specific stack protector compiler sanity-checking script. >> > -ifdef CONFIG_CC_STACKPROTECTOR >> > +ifdef stackp-name >> > + # If the stack protector has been selected, inform the rest of the build. >> > + KBUILD_CFLAGS += -DCONFIG_CC_STACKPROTECTOR >> > + KBUILD_AFLAGS += -DCONFIG_CC_STACKPROTECTOR >> > + # Find arch-specific stack protector compiler sanity-checking script. >> > stackp-path := $(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh >> > stackp-check := $(wildcard $(stackp-path)) >> > endif >> >> >> I have not tested this series, >> but I think this commit is bad (with the follow-up patch applied). >> >> >> I thought of this scenario: >> >> [1] Kernel is configured with CONFIG_CC_STACKPROTECTOR_AUTO >> >> [2] Kernel is built with a compiler without stack protector support. >> >> [3] CONFIG_CC_STACKPROTECTOR is not defined, >> so __stack_chk_fail() is not compiled. >> >> [4] Out-of-tree modules are compiled with a compiler with >> stack protector support. >> __stack_chk_fail() is inserted to functions of the modules. > > We don't ever support the system of loading a module built with anything > other than the _exact_ same compiler than the kernel was. So this will > not happen (well, if someone tries it, they get to keep the pieces their > kernel image is now in...) > >> [5] insmod fails because reference to __stack_chk_fail() >> can not be resolved. > > Even nicer, we failed "cleanly" :) > > This isn't a real-world issue, sorry. If we wanted a slightly different failure, we could simply add the stack protection feature to the VERMAGIC_STRING define: Do you want me to send this patch, or should we allow it to fail with the "missing reference" (which may actually be more expressive...) I think the way it is right now is better, but I'm open to either. -Kees diff --git a/include/linux/vermagic.h b/include/linux/vermagic.h index af6c03f7f986..300163aba666 100644 --- a/include/linux/vermagic.h +++ b/include/linux/vermagic.h @@ -30,11 +30,19 @@ #else #define MODULE_RANDSTRUCT_PLUGIN #endif +#if defined(__SSP__) +#define MODULE_STACKPROTECTOR "stack-protector " +#elif define (__SSP_STRONG__) +#define MODULE_STACKPROTECTOR "stack-protector-strong " +#else +#define MODULE_STACKPROTECTOR "" +#endif #define VERMAGIC_STRING \ UTS_RELEASE " " \ MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT \ MODULE_VERMAGIC_MODULE_UNLOAD MODULE_VERMAGIC_MODVERSIONS \ MODULE_ARCH_VERMAGIC \ + MODULE_STACKPROTECTOR \ MODULE_RANDSTRUCT_PLUGIN