From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755851AbdETIwD (ORCPT ); Sat, 20 May 2017 04:52:03 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:47126 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868AbdETIv6 (ORCPT ); Sat, 20 May 2017 04:51:58 -0400 Date: Sat, 20 May 2017 10:51:47 +0200 From: Greg KH To: Igor Stoppa Cc: mhocko@kernel.org, dave.hansen@intel.com, labbott@redhat.com, linux-mm@kvack.org, kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org Subject: Re: [kernel-hardening] [PATCH 1/1] Sealable memory support Message-ID: <20170520085147.GA4619@kroah.com> References: <20170519103811.2183-1-igor.stoppa@huawei.com> <20170519103811.2183-2-igor.stoppa@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170519103811.2183-2-igor.stoppa@huawei.com> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent pools of memory, > which can be individually created, sealed/unsealed and destroyed. > > A global pool is made available for those kernel modules that do not > need to manage an independent pool. > > Signed-off-by: Igor Stoppa > --- > mm/Makefile | 2 +- > mm/smalloc.c | 200 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > mm/smalloc.h | 61 ++++++++++++++++++ > 3 files changed, 262 insertions(+), 1 deletion(-) > create mode 100644 mm/smalloc.c > create mode 100644 mm/smalloc.h This is really nice, do you have a follow-on patch showing how any of the kernel can be changed to use this new subsystem? Without that, it might be hard to get this approved (we don't like adding new apis without users.) thanks, greg k-h