From patchwork Wed Apr 10 13:17:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 10893903 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 A495B922 for ; Wed, 10 Apr 2019 13:35:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 94B2428A8E for ; Wed, 10 Apr 2019 13:35:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 892F128A97; Wed, 10 Apr 2019 13:35:16 +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 9273E28A89 for ; Wed, 10 Apr 2019 13:35:15 +0000 (UTC) Received: (qmail 17977 invoked by uid 550); 10 Apr 2019 13:35:12 -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 1116 invoked from network); 10 Apr 2019 13:18:27 -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=9/zlh/3sxPGKcfLIkzP+xBRpTq+NAnKSicEM/b1eERc=; b=nEDIMakefZ59hWgJSjJrBxVVAGOBIM9XdMIdJIkLpmMzwJULYzMLpiQFaj0EKyRhTZ MWtHj9ynvRau0B223C8S0MvM3OpSEm3BNoMXf4jHvXgM6dANp4vHj4rgZ2jKY3z32BT6 tsqnSIVvaVuTskvpXlTG5lhLEoSmupOPwRsO+43Stk0BBBzjLnKfxy6z+AupmQpTnr3x vqG56gL+nPwxBwGx9puErENDt7eFK93CFyc1oh6xvEI2nkwk4VKnnSR4f/S7l2sNQDE1 pU+UasSUFtquLV8OdGBz/YZlQuS0NoDAozMtY6SHuiBrurDpo8wsq9Yl0UjqcpSsyeWx aK6g== 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=9/zlh/3sxPGKcfLIkzP+xBRpTq+NAnKSicEM/b1eERc=; b=Sseb6l51wTNqWIaOOJcLQ6DdJW7JY9cKcKZBBXvYzn5X1bicspB661di6pa9COBgnC nrzK2pVTkcYUQ1PwQF2m/cBxgNNaVMRU980dHMCyds3r5YjbqoMSvC+zaeUKpEwYOxcT xRhQws6wvMMt65vHlKWK2T8F5zjX9V/MS03vqf43uv1ISQuTHjkgjvvLzrcRJTgs1lJF vVUI9dFeKgcvY7VBpD78y0UdG9EgvZlZRMGNxbg0llv4xk1/ep6oh7Y66Qoosy8fgo5f 6WmIwk8hp+59I0umNJpLsmekhhPhv7OEB8j1oUOWUsFrktMqfdHCpk/BoW4Q/EfxKFLg YvHA== X-Gm-Message-State: APjAAAWB0yODRChETguurAP7yGIFh/ahlj52ouNo9lDzlF1WM8bDdlcm LFxfbp309SxnsZGstrdte4Tg6IY7KRg= X-Google-Smtp-Source: APXvYqzKOIC96pz5L6dtb2vR7YmWd1kjIM3HHWd3xhWA28i3pJp99Z1EzMyaik4NFVrPlp3qU0925IZvnTc= X-Received: by 2002:a81:994d:: with SMTP id q74mr8139613ywg.18.1554902295333; Wed, 10 Apr 2019 06:18:15 -0700 (PDT) Date: Wed, 10 Apr 2019 15:17:23 +0200 Message-Id: <20190410131726.250295-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.21.0.392.gf8f6787159e-goog Subject: [PATCH v4 0/3] 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, labbott@redhat.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 done in the places that previously checked for __GFP_ZERO to initialize the newly allocated memory. Alexander Potapenko (3): initmem: introduce CONFIG_INIT_ALL_MEMORY and CONFIG_INIT_ALL_STACK initmem: introduce CONFIG_INIT_ALL_HEAP net: make sk_prot_alloc() work with CONFIG_INIT_ALL_HEAP Makefile | 10 ++++++ arch/arm64/Kconfig | 1 + arch/arm64/include/asm/page.h | 1 + arch/x86/Kconfig | 1 + arch/x86/include/asm/page_64.h | 10 ++++++ arch/x86/lib/clear_page_64.S | 24 ++++++++++++++ drivers/infiniband/core/uverbs_ioctl.c | 4 +-- include/linux/gfp.h | 10 ++++++ include/linux/highmem.h | 8 +++++ include/net/sock.h | 8 ++--- kernel/kexec_core.c | 8 +++-- mm/dmapool.c | 4 +-- mm/page_alloc.c | 9 ++++-- mm/slab.c | 19 ++++++++---- mm/slub.c | 12 ++++--- net/core/sock.c | 5 +-- security/Kconfig | 1 + security/Kconfig.initmem | 43 ++++++++++++++++++++++++++ 18 files changed, 154 insertions(+), 24 deletions(-) create mode 100644 security/Kconfig.initmem