From patchwork Wed Jun 26 12:19:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 11017777 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 5CE3C1575 for ; Wed, 26 Jun 2019 12:36:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4BF9927FB7 for ; Wed, 26 Jun 2019 12:36:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3F5DE28437; Wed, 26 Jun 2019 12:36: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=-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 455B627FB7 for ; Wed, 26 Jun 2019 12:36:29 +0000 (UTC) Received: (qmail 15636 invoked by uid 550); 26 Jun 2019 12:36:27 -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 30090 invoked from network); 26 Jun 2019 12:20:00 -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=2Fq0HjbifmsdupktcfAuEl6sSbOWTKpMU8wUfFApIcI=; b=h8oRe74wvAhFNxCVSSLhgtaf8DdDRcvv2LUELZFKlhxIfMWHkB06yNG7SNT3CIncbO xrYAcYPkEKjnBbVe2WkkxpRSyACn/8q3L802S7S92zdmpj8B19KqEVJcOM2de/TNEknR +94Tt3chS1BA9EQxdCUwN45Wrz3UQ2wxYNt9NaVvGQq71AgKto3OiuqHn7RxyjdL02P3 kTB2Ww3CiDQVdnviX+kBmfbmKcALIJ+dol51U9jzsfedTnn6SYA/TwGSVoVw9zlhWnSb 4EeKQMkev9uTpqQzluNSwGkO5ukTgZfcxz/SaVb7HtKHx/CIH57gzcebuKUlYjgHmyus M3AQ== 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=2Fq0HjbifmsdupktcfAuEl6sSbOWTKpMU8wUfFApIcI=; b=hQoIzLbxjXnY9lCavF1+gWqiAidIKH0gwEecQNhM++jT5yo7jsXEHHjAQuLOEgHEwl TjVvlheo1dQbzqW50Pxkj5O/fOMn3/ONP3keAiR32mTNxzG0r44suduK1lCrm8c91hCR xmZrnZ5vpVpZ0c7/ZWClzzO1olOaxjr+H6WXBU8bkp7YHsCpuMH8TzZYv1DgOwqajRzQ mS5+6LRN02lwegyfya/P5iwYIWCo0Sk+ClTMj9b0WZmNuVhSw1F4gfshCAuj3UUHu+O5 9tPyVDTVmOUNBCfF1VmCtbYwefUYrKImv0LHOn87+YMMeUvFNgju4cQbtOQt/kDO+Z1m uwlA== X-Gm-Message-State: APjAAAVDvjVClROBPIQIroWPFRQ7U6K4Jlk0nx0rehEOle5s0R5xHJTk sC6dsvK6+qjPX9y41EbfsQznEUSsqlI= X-Google-Smtp-Source: APXvYqwCAtzX9p5b1vV/t1GUdeUyS8l0gHd33EslOH8hxFCkdYOBd6HFsLdwDix1xDg/zZ5Qa9VT7wjTypQ= X-Received: by 2002:a0c:d249:: with SMTP id o9mr3328284qvh.196.1561551587948; Wed, 26 Jun 2019 05:19:47 -0700 (PDT) Date: Wed, 26 Jun 2019 14:19:41 +0200 Message-Id: <20190626121943.131390-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.22.0.410.gd8fdbe21b5-goog Subject: [PATCH v8 0/3] add init_on_alloc/init_on_free boot options From: Alexander Potapenko To: Andrew Morton , Christoph Lameter , Kees Cook Cc: Alexander Potapenko , Masahiro Yamada , Michal Hocko , James Morris , "Serge E. Hallyn" , Nick Desaulniers , Kostya Serebryany , Dmitry Vyukov , Sandeep Patil , Laura Abbott , Randy Dunlap , Jann Horn , Mark Rutland , Marco Elver , Qian Cai , linux-mm@kvack.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com X-Virus-Scanned: ClamAV using ClamSMTP Provide init_on_alloc and init_on_free boot options. These are aimed at preventing possible information leaks and making the control-flow bugs that depend on uninitialized values more deterministic. Enabling either of the options guarantees that the memory returned by the page allocator and SL[AU]B is initialized with zeroes. SLOB allocator isn't supported at the moment, as its emulation of kmem caches complicates handling of SLAB_TYPESAFE_BY_RCU caches correctly. Enabling init_on_free also guarantees that pages and heap objects are initialized right after they're freed, so it won't be possible to access stale data by using a dangling pointer. As suggested by Michal Hocko, right now we don't let the heap users to disable initialization for certain allocations. There's not enough evidence that doing so can speed up real-life cases, and introducing ways to opt-out may result in things going out of control. To: Andrew Morton To: Christoph Lameter To: Kees Cook Cc: Masahiro Yamada Cc: Michal Hocko Cc: James Morris Cc: "Serge E. Hallyn" Cc: Nick Desaulniers Cc: Kostya Serebryany Cc: Dmitry Vyukov Cc: Sandeep Patil Cc: Laura Abbott Cc: Randy Dunlap Cc: Jann Horn Cc: Mark Rutland Cc: Marco Elver Cc: Qian Cai Cc: linux-mm@kvack.org Cc: linux-security-module@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Alexander Potapenko (2): mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options mm: init: report memory auto-initialization features at boot time .../admin-guide/kernel-parameters.txt | 9 +++ drivers/infiniband/core/uverbs_ioctl.c | 2 +- include/linux/mm.h | 22 ++++++ init/main.c | 24 +++++++ mm/dmapool.c | 4 +- mm/page_alloc.c | 71 +++++++++++++++++-- mm/slab.c | 16 ++++- mm/slab.h | 19 +++++ mm/slub.c | 43 +++++++++-- net/core/sock.c | 2 +- security/Kconfig.hardening | 29 +++++++++ 12 files changed, 204 insertions(+), 19 deletions(-) --- v3: dropped __GFP_NO_AUTOINIT patches v5: dropped support for SLOB allocator, handle SLAB_TYPESAFE_BY_RCU v6: changed wording in boot-time message v7: dropped the test_meminit.c patch (picked by Andrew Morton already), minor wording changes v8: fixes for interoperability with other heap debugging features