From patchwork Fri Mar 8 13:26:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 10844953 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 0B1211390 for ; Fri, 8 Mar 2019 14:02:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EA2862E365 for ; Fri, 8 Mar 2019 14:02:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D9A5E2E478; Fri, 8 Mar 2019 14:02:38 +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 C98252E365 for ; Fri, 8 Mar 2019 14:02:37 +0000 (UTC) Received: (qmail 5641 invoked by uid 550); 8 Mar 2019 14:02:36 -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 10195 invoked from network); 8 Mar 2019 13:27:18 -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=ITxJ4DVi5/l/txR4/Ov/77/J0tyE1RyIZzC1WnI2dps=; b=uHJY6Dx3zxq51iFiZHcMLg6tWrh4gI9uXR3vNUXhIUVJXFuPx6b5TB8isN30eVgr1Q OT8xLTTXFNaGKMmrRD+SUINlCtA62ws/W5hGZbkO8ZpSIyz74sPTfGcVAYJRLJtb7j+T KJwu481nN4rIBM5KAsoXxlAqcvkQfEkvzSVeXG+byK4UjvQssQydkB+bIUQ1WRCbO/Al gLjKHjW3CQC/fr9fKyAut9Yh1hDUNc34ylGXBsHzx8BKKZM9bo77s++4yT6GZerNVpQo WHbof3h6mTE1is7OtRv+xfCG1L17D0c5HjuhK0BX0hWPItiDKeNmRT/A7c8SKEA1D4th 4Ipg== 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=ITxJ4DVi5/l/txR4/Ov/77/J0tyE1RyIZzC1WnI2dps=; b=oHMaJxgJ9vBHlJ2ziTgqQjcQpcuteVMArJcTsf1thIZ5mPVjIAvphWeZJiqWsWNGyR 9Z6CNyQnrz/+8ihwSSF/ahOhOZkpjjZg0UrVg3NBSi0fUYCb1vgVX+RTVYbBteOyjJj+ Zn/cEAPFbPiof2I+o5hW3QZ6GwurzIARbowXpc+Pne5QN59ZXnjpnfGmXgm6KbG647mX pFh7avx/RKwIt4+GxMdymY6Ha9X0vcUA0k33IJtyJ7EdzSD4vXvwaNPoHgOOgM0ZjDw9 morgXpuhNh9U+kNTD2oyP9ypI2xWmj/pUCnxgd9As9r/s2CzxMbpVMZFFElK5mKZKYAD ykCg== X-Gm-Message-State: APjAAAXXcHaYaFJssyZHTJMJfab6j5bTH3MfqplWHuZboFrdwsG2QbOb xPvHx3kEuNVlUVObCLB/rjIXfS8EwhM= X-Google-Smtp-Source: APXvYqywMqhV9eMkPfFNzDOrgKegMbyDfouE8Wd+4w50Y8ZyTFSbINYzxSrtswQw8TGuZFu4DI8s+oQ7PBk= X-Received: by 2002:a25:8b0f:: with SMTP id i15mr9074047ybl.32.1552051626130; Fri, 08 Mar 2019 05:27:06 -0800 (PST) Date: Fri, 8 Mar 2019 14:26:59 +0100 Message-Id: <20190308132701.133598-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.21.0.360.g471c308f928-goog Subject: [PATCH v2 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 ++++++++++ scripts/Makefile.lib | 6 ++++++ security/Kconfig | 1 + security/Kconfig.initmem | 40 ++++++++++++++++++++++++++++++++++++++++ 7 files changed, 66 insertions(+), 1 deletion(-) create mode 100644 scripts/Makefile.initmem create mode 100644 security/Kconfig.initmem