From patchwork Tue Mar 20 03:10:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10296175 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 9C22060385 for ; Tue, 20 Mar 2018 03:10:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8F0D8290F9 for ; Tue, 20 Mar 2018 03:10:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 838DB291E3; Tue, 20 Mar 2018 03:10:32 +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.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 877F7290F9 for ; Tue, 20 Mar 2018 03:10:30 +0000 (UTC) Received: (qmail 30148 invoked by uid 550); 20 Mar 2018 03:10:26 -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 30119 invoked from network); 20 Mar 2018 03:10:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OTv8nFhMmaKR0uFi5wqmC3CbIlISij8Kn4L/bJTGf/w=; b=NMinMgtKErCVs40lGetJ6krwMbyhkb8KIKnPv5q7eqZkQF/iOHiou8ku/2Xf6vAyhx GdAMwJyH0GVVEzjmgcBF+WqFdfs5QruhQ51+8HvtjjJ0X+7I0GKos7joQray8+QqA3oN srCkVL6aN6b3JEQH8pt18APobDXp4P9Pz4r65DW6r5euiRIvYPMPgmqjQWwNvsO7tFkg t/3v9b3pstLTc6wF7Krkcm2ggnwDltaVxHvFqufNB/0utDWGnUwjEOryf32JfREBilqA rvkoubB2SoL7ThW8QcT3PNPsyYREPnMzgIrPknel15edQzR2S2l1DrHVk+zMDxzQthxj H7pA== 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=OTv8nFhMmaKR0uFi5wqmC3CbIlISij8Kn4L/bJTGf/w=; b=I4NTKhSh/5W6J+wUVWowpsDvlRpzLE/QJKvK1NmbAtwZ5kj7OJ3z+9aIKCWmaVh/jJ uA+t/pih+BiOVdUPxHQ3/NvF4O2+53RVRnHYhNB2iDmlGU/6cnjVXlYKmhEeYhkc6b6k LdOSzdCZu6Pe3uSPMJ6rEY/XadWyAnT5heQtNG4Y9ox5bnpuzQVP5sIlWfMxdt65kXEy gtsq5tBKmGHrz6eUfKjBR2JuQaoaH/8npTT3B30rFGeIsLeNlNckNr9Uz5opc8wWNdhP xLzQKgqKnndsvcesWU1w4iONtFvgpi1Juv8mb/ONXhxY05XM3jvvNRPZVPVAEzJxLa/A mjuw== X-Gm-Message-State: AElRT7FTdebLsdCy+cwuidwWsZKalBUUMR1RwuwNeZsk3EV0pWqDor4b DVYxY5DuKjhHpIFOY8h8Lrc/HwkslmXjGKCGkGk= X-Google-Smtp-Source: AG47ELvs0qhFUJwHBlVEia4edOlAVtVDNbjAf+VLbVXMvAiYHG4/U3Af9dv2BZWh43t7JZaL/Y6rCHW1afbFcRRdrnU= X-Received: by 10.200.56.177 with SMTP id f46mr22740314qtc.9.1521515413066; Mon, 19 Mar 2018 20:10:13 -0700 (PDT) MIME-Version: 1.0 Sender: arndbergmann@gmail.com In-Reply-To: References: <1521174359-46392-1-git-send-email-keescook@chromium.org> <20180316175502.GE30522@ZenIV.linux.org.uk> <42b4342b-aefc-a16a-0d43-9f9c0d63ba7a@rasmusvillemoes.dk> <38b6da49-1138-017e-7307-f39ff067d6d2@rasmusvillemoes.dk> <0e94e9582bec4373b5e21c612be179ac@AcuMS.aculab.com> From: Arnd Bergmann Date: Tue, 20 Mar 2018 11:10:12 +0800 X-Google-Sender-Auth: 5Q0Lx5VtBJc2X9EAJQHvD9nAgHY Message-ID: Subject: Re: [PATCH v5 0/2] Remove false-positive VLAs when using max() To: Linus Torvalds Cc: David Laight , Rasmus Villemoes , Kees Cook , Al Viro , Florian Weimer , Andrew Morton , Josh Poimboeuf , Randy Dunlap , Miguel Ojeda , Ingo Molnar , Ian Abbott , linux-input , linux-btrfs , Network Development , Linux Kernel Mailing List , Kernel Hardening X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Mar 20, 2018 at 7:29 AM, Linus Torvalds wrote: > On Mon, Mar 19, 2018 at 2:43 AM, David Laight wrote: >> >> Is it necessary to have the full checks for old versions of gcc? >> >> Even -Wvla could be predicated on very recent gcc - since we aren't >> worried about whether gcc decides to generate a vla, but whether >> the source requests one. > > You are correct. We could just ignore the issue with old gcc versions, > and disable -Wvla rather than worry about it. This version might also be an option: Wiht -Wstack-usage=, we should get a similar warning to -Wvla for frames that contain real VLAs, but not when there is a VLA that ends up being a compile-time constant size in the end. Wstack-usage was introduced in gcc-4.7, so on older versions it turns back into Wframe-larger-than=. An example output would be security/integrity/ima/ima_crypto.c: In function 'ima_calc_buffer_hash': security/integrity/ima/ima_crypto.c:616:5: error: stack usage might be unbounded [-Werror=stack-usage=] Arnd diff --git a/Makefile b/Makefile index 37fc475a2b92..49dd9f0fb76c 100644 --- a/Makefile +++ b/Makefile @@ -687,7 +687,8 @@ KBUILD_CFLAGS += $(call cc-option,-fno-reorder-blocks,) \ endif ifneq ($(CONFIG_FRAME_WARN),0) -KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN}) +KBUILD_CFLAGS += $(call cc-option,-Wstack-usage=${CONFIG_FRAME_WARN}, \ + -$(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})) endif # This selects the stack protector compiler flag. Testing it is delayed