Received: by 10.223.185.116 with SMTP id b49csp6600131wrg; Wed, 28 Feb 2018 12:08:12 -0800 (PST) X-Google-Smtp-Source: AH8x2271cRMb8g2D2uEul71SJkFVU5/CjvbXW/z1CV1o3USQgcOexQj42T4SvUGTUYejaCumtnEm X-Received: by 2002:a17:902:40a:: with SMTP id 10-v6mr19199280ple.245.1519848492672; Wed, 28 Feb 2018 12:08:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519848492; cv=none; d=google.com; s=arc-20160816; b=aHKhpo7zLHnWi3oZKJhm1keoJhrr5szInm1gSgZblXGlsRPoDwgVWtpS5ys/q6wvZv k/GKYeUejE7imaPWeWwQYZXlYNlJpfU48NneGk41vvifWL0PhCLIvtYkBDiR/tGTuY1z rlZLuBHuPJIYY9S0TQIG16QZukkFw0IkhRb5H/l2Fv5SfpzylCuwpLNX1hI1k+pY7jma VzYJyXHb6uIUKZvzAmemLZP77GaHWUQmIi0kXyAnT8r/D/d3W0HQoIdV+PygYPQj1p0J 1OI9MHuktPo7Rffb+AV94ec5RSsSDg5nPHYOknoEVOqsY+odXG7S2oSYUfhCsO7KTDWH A9DA== 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=kSVZNwoDsTfUES7aPGpLCQEyU0qIi11adqSESl/nMxU=; b=tr9Y1fx3jR8M4ljCtA+AwCFCIMYcpaW2Q91eSSk49I0PKA1rpRmgTd9G0JHbxgQXsa kimaRxO8pXAUu4pAXjsk5aUnfnyVmB/YcSyOk0w9kq7ZGbpTZOg0KrJup9NcW9HYHoTi 1h985wfI+5SlTxII8lk3o1Lwi8qvG9b/GyEDcBY1Np7vaXtd9M/zl9fFxTp+YVZ1lk4Y YXnx4LVmWenTHmFXsgDwVvvvUtaexzAGQKeIOgyMpvn13c/bY/GIg+vyM7M9/kowedyS maKNSQneIGE2iQcLACPzG40C5t7POsvbOepM1c6TbWmMLvAWcj1o/1RU7gyqXdcwDf6G 4kuA== 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 1-v6si1754197plk.52.2018.02.28.12.07.57; Wed, 28 Feb 2018 12:08:12 -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 S934125AbeB1UHH (ORCPT + 99 others); Wed, 28 Feb 2018 15:07:07 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:27892 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933981AbeB1UHF (ORCPT ); Wed, 28 Feb 2018 15:07:05 -0500 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7FE9BD5407FE4; Wed, 28 Feb 2018 20:07:02 +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; Wed, 28 Feb 2018 20:06:58 +0000 From: Igor Stoppa To: , , , CC: , , , , , Igor Stoppa Subject: [RFC PATCH v18 0/7] mm: security: ro protection for dynamic data Date: Wed, 28 Feb 2018 22:06:13 +0200 Message-ID: <20180228200620.30026-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 v17: * turned all BUGs into WARNs, with the exceptions of the (optional) genalloc selftesting * added mode descriptive messages, in case of failures * fixed incorrect description of behavior when destroying a pool * added tetst case of allocating memory from protected pool * fixed kerneldoc description also for genalloc.h * added missing Kconfig dependency for pmalloc, on MMU * fixed location of initialization of link page struct -> vm_area Igor Stoppa (7): genalloc: track beginning of allocations genalloc: selftest struct page: add field for vm_struct Protectable Memory Pmalloc selftest lkdtm: crash on overwriting protected pmalloc var Documentation for Pmalloc Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 111 ++++++ drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_core.c | 3 + drivers/misc/lkdtm_perms.c | 28 ++ include/linux/genalloc.h | 367 +++++++++++++++--- include/linux/mm_types.h | 1 + include/linux/pmalloc.h | 242 ++++++++++++ include/linux/test_genalloc.h | 26 ++ include/linux/test_pmalloc.h | 24 ++ include/linux/vmalloc.h | 1 + init/main.c | 4 + lib/Kconfig | 15 + lib/Makefile | 1 + lib/genalloc.c | 745 +++++++++++++++++++++++++++---------- lib/test_genalloc.c | 410 ++++++++++++++++++++ mm/Kconfig | 17 + mm/Makefile | 2 + mm/pmalloc.c | 468 +++++++++++++++++++++++ mm/test_pmalloc.c | 100 +++++ mm/usercopy.c | 33 ++ mm/vmalloc.c | 2 + 22 files changed, 2364 insertions(+), 238 deletions(-) create mode 100644 Documentation/core-api/pmalloc.rst create mode 100644 include/linux/pmalloc.h create mode 100644 include/linux/test_genalloc.h create mode 100644 include/linux/test_pmalloc.h create mode 100644 lib/test_genalloc.c create mode 100644 mm/pmalloc.c create mode 100644 mm/test_pmalloc.c -- 2.14.1