From patchwork Thu May 23 12:42:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 10957545 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 820666C5 for ; Thu, 23 May 2019 12:42:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 68D3028496 for ; Thu, 23 May 2019 12:42:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5D0E028498; Thu, 23 May 2019 12:42:27 +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=-14.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3BDAB28496 for ; Thu, 23 May 2019 12:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729962AbfEWMmZ (ORCPT ); Thu, 23 May 2019 08:42:25 -0400 Received: from mail-yb1-f201.google.com ([209.85.219.201]:38541 "EHLO mail-yb1-f201.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729361AbfEWMmZ (ORCPT ); Thu, 23 May 2019 08:42:25 -0400 Received: by mail-yb1-f201.google.com with SMTP id a13so5107901ybm.5 for ; Thu, 23 May 2019 05:42:24 -0700 (PDT) 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=JQ1oCxUU1IPVRVLwTDKqVi9a5cWuQ5HVxcskTOhO4aM=; b=ertiE0SB+mfT4MEk0SFpNz/YKadHtLe1893I517U4tFeM8uM4swKr9G/SikceY0rCZ UDv4kifx0Bx26JjS24LlGhSYfY5dn5hLUvIS+argIdWCUpj1zPlvl2vgcVT7VlYsMIBc TbZHChjMXWT1nZTF2UxhG3QQeuTGjHcBqomUaPOhXB56N+mygLlEEWcHWhxicHOP9S1B 5KxHPYzkoVGX7YeFgoThDuFVkgEJqn+ZZYDjNKrKzE9PsO+fkj2QIaVmmjg9RyHD6UE+ GLNEbVFhskq2fbM3GBHi68kjqbHgC7bL3loysl7MiurRFJlygTNNkqpkXQbKQ7K1eIxr EB9A== 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=JQ1oCxUU1IPVRVLwTDKqVi9a5cWuQ5HVxcskTOhO4aM=; b=QyFGe+lW0Iw3HxQlul5QvQRNRWDkvtBqq0POwJze1+v2Ih48I2topdXK/RGrT8XZnd 4eB68US+425OBJKr9dJLqu1yF/h7FrsRieV5/zU3MkghTPnDva2zcFGDCucugDlY225n EenhgzVnHj+G2dyWPHwTUofy28FMjMPfNb1kw3aaJMVaaxs1yf1Kzx/htXTc+RxgosX/ sEbIWXu1MnaSCP/pe6Kly5cyFaLmR1lGwF06dApL3RuzW9/lpwsPS27o21dDH4EIk6O3 GqHSDjEPlckMBGDcx8F68Gg5OaLQ8OsmJdftP5AWhOCOt9XtJOtBnkPdzxZHGA+TJNfa Febw== X-Gm-Message-State: APjAAAXhUa9cXOfhFzkCO7L8ozOthqzf8mUc75MeFGHiPeCQm5xkTuvA QGDgLn+PBvnYb08wrwHdLR+i5AlJ020= X-Google-Smtp-Source: APXvYqybh08sHeGZRRlBZ+rEKGpK9UKViuwmqgzYonb7VhrGAa6y78I0qkN7CYW3hhy3qjCkZr902YQaq1s= X-Received: by 2002:a81:5987:: with SMTP id n129mr46582349ywb.193.1558615344476; Thu, 23 May 2019 05:42:24 -0700 (PDT) Date: Thu, 23 May 2019 14:42:13 +0200 Message-Id: <20190523124216.40208-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.21.0.1020.gf2820cf01a-goog Subject: [PATCH v3 0/3] RFC: add init_on_alloc/init_on_free boot options From: Alexander Potapenko To: akpm@linux-foundation.org, cl@linux.com, keescook@chromium.org Cc: kernel-hardening@lists.openwall.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: 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[AOU]B is initialized with zeroes. 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. Alexander Potapenko (3): mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options mm: init: report memory auto-initialization features at boot time lib: introduce test_meminit module .../admin-guide/kernel-parameters.txt | 8 + drivers/infiniband/core/uverbs_ioctl.c | 2 +- include/linux/mm.h | 22 ++ init/main.c | 24 ++ kernel/kexec_core.c | 2 +- lib/Kconfig.debug | 8 + lib/Makefile | 1 + lib/test_meminit.c | 208 ++++++++++++++++++ mm/dmapool.c | 2 +- mm/page_alloc.c | 63 +++++- mm/slab.c | 16 +- mm/slab.h | 16 ++ mm/slob.c | 22 +- mm/slub.c | 27 ++- net/core/sock.c | 2 +- security/Kconfig.hardening | 14 ++ 16 files changed, 416 insertions(+), 21 deletions(-) create mode 100644 lib/test_meminit.c --- v3: dropped __GFP_NO_AUTOINIT patches