Received: by 10.223.185.116 with SMTP id b49csp762150wrg; Sat, 10 Feb 2018 19:21:14 -0800 (PST) X-Google-Smtp-Source: AH8x226UAjX2SiOysfTQa5DaCIVG1FUFp31DnTMyV26Go/PURYYVdR9M+3r93KgUISYkkoJ2oNNe X-Received: by 10.98.234.19 with SMTP id t19mr7661566pfh.74.1518319274639; Sat, 10 Feb 2018 19:21:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518319274; cv=none; d=google.com; s=arc-20160816; b=KE8YQ68ZoNHJegtTMSjq0ygZeyvdd+BXQLTo5xg1G8Ub6Wh7f+anv9OkMuEfULOHgD GF8CJtlM7jhzjCLweVYPXVvuaa9OHtNcW/oarxGFP1hJ8NEPpF8fcLKb07AX8Ect2Yid MhINRq5cCy9tQZjFuvRgTIySxHY0y9FRPagrwbsaSFQZVTz7XjBaeT222+jg47Y2an5Q /nwm6ay/PeK9fLuUrV2FZadcq5wRvCGQhNxGAmWLkSKlpUB0xic9r2G5Z+kCA2EJsn2E tYann7s4YcvarAesEup+POK8uzaeVhuh3KQwjl7r1IHjvgWY3mTCAfWUhyMtVRtz5Z2h aSWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=7zMj44DR+KVPrh4isZiUKaD/8f3BK/d2CKcmY2YwjNU=; b=KYo/go1WU+sVB2CGTE98tXSO7oOM3XnvjsrBotggTT2BxMAT1NpYDOUImp+jJzQ4fc eZo2s/SYvS4zqRBVNWSfR6itLoydCi/i7/gFhBQHDSGWxkU5C2eCQsU3bB5FyPPCsWJU 19yaZ6USKB4/O8ZDH363szv0AoTsP7lyKcHE8QuvtdoJuRZbjromzivmqQksOgDVfDjS Q5nCCbA0Zrfqd02b2ejTm35GDkCicVS0/iyvaFVvTrMCaMAPHjoVdcFJjykWKisSVRVO pCTOsQV8iEfsJIqUHO/yWXShJZV5voVduEv5K/4pTV+burTGSrj49TWmyrWOMQBoSdgR Zmmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18si760089pgu.8.2018.02.10.19.21.00; Sat, 10 Feb 2018 19:21:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752223AbeBKDTy (ORCPT + 99 others); Sat, 10 Feb 2018 22:19:54 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:26061 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751921AbeBKDTx (ORCPT ); Sat, 10 Feb 2018 22:19:53 -0500 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 67F50B2DF9277; Sun, 11 Feb 2018 03:19:49 +0000 (GMT) Received: from localhost.localdomain (10.122.225.51) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 11 Feb 2018 03:19:44 +0000 From: Igor Stoppa To: , , , , , , , CC: , , , , , Igor Stoppa Subject: [RFC PATCH v15 0/6] mm: security: ro protection for dynamic data Date: Sun, 11 Feb 2018 05:19:14 +0200 Message-ID: <20180211031920.3424-1-igor.stoppa@huawei.com> X-Mailer: git-send-email 2.14.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch-set introduces the possibility of protecting memory that has been allocated dynamically. The memory is managed in pools: when a memory pool is turned into R/O, all the memory that is part of it, will become R/O. A R/O pool can be destroyed, to recover its memory, but it cannot be turned back into R/W mode. This is intentional. This feature is meant for data that doesn't need further modifications after initialization. However the data might need to be released, for example as part of module unloading. To do this, the memory must first be freed, then the pool can be destroyed. An example is provided, in the form of self-testing. Changes since v14: [http://www.openwall.com/lists/kernel-hardening/2018/02/04/2] - fix various warnings from sparse - multiline comments - fix naming of headers guards - fix compilation of individual patches, for bisect - split genalloc documentation about bitmap for allocation - fix headers to match kerneldoc format for "Return:" field - fix variable naming according to coding guidelines - fix wrong default value for pmalloc Kconfig option - refreshed integration of pmalloc with hardened usercopy - removed unnecessary include that was causing compilation failures - changed license of pmalloc documentation from GPL 2.0 to CC-BY-SA-4.0 Igor Stoppa (6): genalloc: track beginning of allocations genalloc: selftest struct page: add field for vm_struct Protectable Memory Pmalloc: self-test Documentation for Pmalloc Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 114 ++++++++ include/linux/genalloc-selftest.h | 26 ++ include/linux/genalloc.h | 7 +- include/linux/mm_types.h | 1 + include/linux/pmalloc.h | 222 +++++++++++++++ include/linux/vmalloc.h | 1 + init/main.c | 2 + lib/Kconfig | 15 + lib/Makefile | 1 + lib/genalloc-selftest.c | 400 ++++++++++++++++++++++++++ lib/genalloc.c | 554 +++++++++++++++++++++++++++---------- mm/Kconfig | 15 + mm/Makefile | 2 + mm/pmalloc-selftest.c | 63 +++++ mm/pmalloc-selftest.h | 24 ++ mm/pmalloc.c | 499 +++++++++++++++++++++++++++++++++ mm/usercopy.c | 33 +++ mm/vmalloc.c | 18 +- 19 files changed, 1852 insertions(+), 146 deletions(-) create mode 100644 Documentation/core-api/pmalloc.rst create mode 100644 include/linux/genalloc-selftest.h create mode 100644 include/linux/pmalloc.h create mode 100644 lib/genalloc-selftest.c create mode 100644 mm/pmalloc-selftest.c create mode 100644 mm/pmalloc-selftest.h create mode 100644 mm/pmalloc.c -- 2.14.1