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: 9985169 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 225C9605A8 for ; Wed, 4 Oct 2017 16:22:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 14ED828B5F for ; Wed, 4 Oct 2017 16:22:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 09BE828B5E; Wed, 4 Oct 2017 16:22:30 +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=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8C8BE28B5B for ; Wed, 4 Oct 2017 16:22:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751211AbdJDQW2 (ORCPT ); Wed, 4 Oct 2017 12:22:28 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:55160 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169AbdJDQW1 (ORCPT ); Wed, 4 Oct 2017 12:22:27 -0400 Received: by mail-it0-f48.google.com with SMTP id f79so1574582ita.3 for ; Wed, 04 Oct 2017 09:22:27 -0700 (PDT) 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=o3ZunGRdRrMucLXkxZXscGHS8WkGllQvLcu2fnD0oDGEfGDKFJGohloMMwZ1j5WBeZ feKnjHlzDq4eR3H9M0YF7rdQVWw1AhOV+uvyO39WoWg4APyd7KtCEge4jGcs1b7aY1m4 L4xheHBv+rd3O5ahmpEFaq3ojOAuNt3riUcRhBUUQzbyS9mYIlzPYJMDE58hnjYlEUkZ zXKukkKzOdzy0I9b+oxbid7gTCJdFOTX4EYDwQNJLQ67GFd/04R3ZQ0QhGTbRQrRwxyD DcEMG+kB8BBEB8NJAVvriUtaHWzDKqAdpoRMuc1dSWJaFSPqbqzssye2e9xA9WgRggpP zgxw== X-Gm-Message-State: AMCzsaW1fb+KTqr/h2m0rsAfGKf3zxyZ9P87o+DxkhvVGsnUt5SEaPIV Mu5GhvkLSG7xp66NsLvdMKFhRa15+lGWFJ9ebkWqzg== 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 Received: by 10.107.153.79 with HTTP; Wed, 4 Oct 2017 09:22:24 -0700 (PDT) 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: Subject: Re: [kernel-hardening] Re: [PATCH 2/3] Makefile: Move stackprotector availability out of Kconfig 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 Sender: linux-sh-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org 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