From patchwork Mon Apr 8 17:04:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 10889923 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DEE9E1800 for ; Mon, 8 Apr 2019 17:20:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C2C93285C4 for ; Mon, 8 Apr 2019 17:20:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B6A332873C; Mon, 8 Apr 2019 17:20:28 +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=-12.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, USER_IN_DEF_DKIM_WL 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 CAD7028738 for ; Mon, 8 Apr 2019 17:20:22 +0000 (UTC) Received: (qmail 9288 invoked by uid 550); 8 Apr 2019 17:20:11 -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 Delivered-To: moderator for kernel-hardening@lists.openwall.com Received: (qmail 26613 invoked from network); 8 Apr 2019 17:04:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=gJ3i63zTqGOr5CNiCKsCMRuhMkPExPtND8GkfCcQS2Q=; b=YqzP19dHuQebbAYxe2mou1n0zxSnH06cAOlwbvW8kTSCKCgsN1WWn+EvRRQvYZRLdq UCuoIQKHN/4S6Cb0Oy4me/hV7eTDR5eOfalQDYOtJbQ8dpyN2jFDN9o9hz9RC5FuIfiH LuMOYAaB+Z/2GcxW/Oqut/dHgYYGYIdsHufYHOshnik8A7w0xKEuG99r0fqXZQ5o1fta DKsSmsFI0ALEgLi6gsBrLCoFHSdjJhdeJBE1NbPROnAIhj8W5lzXelM7c2tLk9vYXdpe p3EY01Sxnil0YZu1Ra90f4m91LbkKy4H1XxacVXl+ZC65ooINSZb4YF9Zuam14D+TCaE sGGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=gJ3i63zTqGOr5CNiCKsCMRuhMkPExPtND8GkfCcQS2Q=; b=s4Bqq+TNmAJzE/vSQ9WpHakyU5bfWXb19h6Nng4h/+AQYem2ZanM68jXfnj2FZanka 1w3XXfA3zZkCrtIC+E7CEoHUm5c5ayqNY1klrygUvkqY9qY761JjY/+cMglv75wukjGf XdwF/4b2vHGEatfo+toY2cuuZ47An4HyhgWngvQGe4O+0/0C7IBjdoR997+6M5XULUXG e8+I7yGAmtBQdNJ41Kr2pxGJme4nEqA/qGZIKR2GvU1/PQKaDdPHX2ImmdPmeRsfUxrm NlvxtoW5bcgIr1TSb9ZHx67llv1///w1OTOg5sXROXo73BTEEcXTHiG9UzMNYOG67k+/ pLCA== X-Gm-Message-State: APjAAAXR5TSy/E/GCMjyCQdPHgwRFKEl9f9raRqRPrbdNT1YjAkSUGEn IywkFEzd6/wKZDYYALIH46q2S4/+msc= X-Google-Smtp-Source: APXvYqx4BCl069ZIbi878+ZaIUqcQL1mhPGU0o5zACT1AzSsYBxz94b80Lelh1NbqvxY+K6hRYA4amz28DU= X-Received: by 2002:a37:945:: with SMTP id 66mr3615697qkj.60.1554743062602; Mon, 08 Apr 2019 10:04:22 -0700 (PDT) Date: Mon, 8 Apr 2019 19:04:16 +0200 Message-Id: <20190408170418.148554-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.21.0.392.gf8f6787159e-goog Subject: [PATCH v3 0/2] RFC: introduce CONFIG_INIT_ALL_MEMORY From: Alexander Potapenko To: yamada.masahiro@socionext.com, jmorris@namei.org, serge@hallyn.com Cc: linux-security-module@vger.kernel.org, linux-kbuild@vger.kernel.org, ndesaulniers@google.com, kcc@google.com, dvyukov@google.com, keescook@chromium.org, sspatil@android.com, kernel-hardening@lists.openwall.com X-Virus-Scanned: ClamAV using ClamSMTP This patch is a part of a bigger initiative to allow initializing heap/stack memory in the Linux kernels by default. The rationale behind doing so is to reduce the severity of bugs caused by using uninitialized memory. Over the last two years KMSAN (https://github.com/google/kmsan/) has found more than a hundred bugs running in a really moderate setup (orders of magnitude less CPU/months than KASAN). Some of those bugs led to information leaks if uninitialized memory was copied to the userspace, other could cause DoS because of subverted control flow. A lot more bugs remain uncovered, so we want to provide the distros and OS vendors with a last resort measure to mitigate such bugs. Our plan is to introduce configuration flags to force initialization of stack and heap variables with a fixed pattern. This is going to render information leaks inefficient (as we'll only leak pattern data) and make uses of uninitialized values in conditions more deterministic and discoverable. The stack instrumentation part is based on Clang's -ftrivial-auto-var-init (see https://reviews.llvm.org/D54604 ; there's also a GCC feature request for a similar flag: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210) or GCC's -fplugin-arg-structleak_plugin-byref-all The heap initialization part is compiler-agnostic and is based on the existing CONFIG_SLUB_DEBUG and CONFIG_PAGE_POISONING. Alexander Potapenko (2): initmem: introduce CONFIG_INIT_ALL_MEMORY and CONFIG_INIT_ALL_STACK initmem: introduce CONFIG_INIT_ALL_HEAP Makefile | 3 ++- mm/page_poison.c | 5 +++++ mm/slub.c | 2 ++ scripts/Makefile.initmem | 10 ++++++++++ security/Kconfig | 1 + security/Kconfig.initmem | 40 ++++++++++++++++++++++++++++++++++++++++ 6 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 scripts/Makefile.initmem create mode 100644 security/Kconfig.initmem