Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-05 Thread Igor Stoppa
On 04/05/17 19:49, Laura Abbott wrote: > [adding kernel-hardening since I think there would be interest] thank you, I overlooked this > BPF takes the approach of calling set_memory_ro to mark regions as > read only. I'm certainly over simplifying but it sounds like this > is mostly a mechanism

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-05 Thread Igor Stoppa
On 04/05/17 20:24, Dave Hansen wrote: > On 05/04/2017 07:01 AM, Michal Hocko wrote: >> Just to make my proposal more clear. I suggest the following workflow >> >> cache = kmem_cache_create(foo, object_size, ..., SLAB_SEAL); >> >> obj = kmem_cache_alloc(cache, gfp_mask); >> init_obj(obj) >> [more

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-05 Thread Igor Stoppa
On 04/05/17 17:01, Michal Hocko wrote: > On Thu 04-05-17 16:37:55, Igor Stoppa wrote: [...] >> The disadvantage is that anything can happen, undetected, while the seal >> is lifted. > > Yes and I think this makes it basically pointless ok, this goes a bit beyond what I

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

2017-05-22 Thread Igor Stoppa
On 20/05/17 11:51, Greg KH wrote: > On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: >> Dynamically allocated variables can be made read only, [...] > This is really nice, do you have a follow-on patch showing how any of > the kernel can be changed to use this new

Re: [PATCH] LSM: Make security_hook_heads a local variable.

2017-05-22 Thread Igor Stoppa
On 22/05/17 18:09, Casey Schaufler wrote: > On 5/22/2017 7:03 AM, Christoph Hellwig wrote: [...] >> But even with those we can still chain >> them together with a list with external linkage. > > I gave up that approach in 2012. Too many unnecessary calls to > null functions, and massive

Re: [PATCH 1/1] Sealable memory support

2017-05-23 Thread Igor Stoppa
On 23/05/17 00:38, Kees Cook wrote: > On Fri, May 19, 2017 at 3:38 AM, Igor Stoppa wrote: [...] > For the first bit of bikeshedding, should this really be called > seal/unseal? My mind is probably just broken from having read TPM > documentation, but this isn't really &quo

Re: [PATCH 1/1] Sealable memory support

2017-05-24 Thread Igor Stoppa
On 23/05/17 23:11, Kees Cook wrote: > On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa wrote: [...] > I would want hardened usercopy support as a requirement for using > smalloc(). Without it, we're regressing the over-read protection that > already exists for slab objects, if

[RFC v3]mm: ro protection for data allocated dynamically

2017-05-19 Thread Igor Stoppa
Hooks - policy database of SE Linux (several different structure types) Igor Stoppa (1): Sealable memory support mm/Makefile | 2 +- mm/smalloc.c | 200 +++ mm/smalloc.h | 61 ++ 3 files changed, 262 insertions(+), 1

[PATCH 1/1] Sealable memory support

2017-05-19 Thread Igor Stoppa
. 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

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-19 Thread Igor Stoppa
Hello, On 10/05/17 18:45, Dave Hansen wrote: > On 05/10/2017 08:19 AM, Igor Stoppa wrote: >> So I'd like to play a little what-if scenario: >> what if I was to support exclusively virtual memory and convert to it >> everything that might need sealing? > > Be

Re: [PATCH v7 0/7] Introduce ZONE_CMA

2017-05-02 Thread Igor Stoppa
On 02/05/17 16:03, Michal Hocko wrote: > I can imagine that we could make ZONE_CMA configurable in a way that > only very well defined use cases would be supported so that we can save > page flags space. But this alone sounds like a maintainability nightmare > to me. Especially when I consider

RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-03 Thread Igor Stoppa
Hello, please review my (longish) line of thoughts, below. I've restructured them so that they should be easier to follow. Observations * it is currently possible, by using prefix "__read_only", to have the linker place a static variable into a special memory region, which will

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-04 Thread Igor Stoppa
Hi, I suspect this was accidentally a Reply-To instead of a Reply-All, so I'm putting back the CCs that were dropped. On 03/05/17 21:41, Dave Hansen wrote: > On 05/03/2017 05:06 AM, Igor Stoppa wrote: >> My starting point are the policy DB of SE Linux and the LSM Hooks, but >> eve

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-09 Thread Igor Stoppa
On 08/05/17 18:25, Laura Abbott wrote: > On 05/05/2017 03:42 AM, Igor Stoppa wrote: >> On 04/05/17 19:49, Laura Abbott wrote: [...] > PAGE_SIZE is still 4K/16K/64K but the underlying page table mappings > may use larger mappings (2MB, 32M, 512M, etc.). The ARM architecture >

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-10 Thread Igor Stoppa
On 10/05/17 11:05, Michal Hocko wrote: > On Fri 05-05-17 13:42:27, Igor Stoppa wrote: [...] >> ... in the case I have in mind, I have various, heterogeneous chunks of >> data, coming from various subsystems, not necessarily page aligned. >> And, even if they were page

Re: RFC v2: post-init-read-only protection for data allocated dynamically

2017-05-10 Thread Igor Stoppa
On 10/05/17 14:43, Michal Hocko wrote: > On Wed 10-05-17 11:57:42, Igor Stoppa wrote: >> On 10/05/17 11:05, Michal Hocko wrote: > [...] >>> To me it seems that this being an initialization mostly thingy a simple >>> allocator which manages a pool of pa

Re: [PATCH 2/4] Protectable Memory Allocator

2017-06-19 Thread Igor Stoppa
On 09/06/17 21:56, Laura Abbott wrote: > On 06/07/2017 05:35 AM, Igor Stoppa wrote: [...] > The pool logic looks remarkably similar to genalloc (lib/genalloc.c). > It's not a perfect 1-to-1 mapping but it's close enough to be worth > a look. Indeed. I have prepared a new incarnatio

[PATCH v6 0/4] ro protection for dynamic data

2017-06-07 Thread Igor Stoppa
, according to Casey. Igor Stoppa (3): Protectable Memory Allocator Protectable Memory Allocator - Debug interface Make LSM Writable Hooks a command line option Tetsuo Handa (1): LSM: Convert security_hook_heads into explicit array of struct list_head include/linux/lsm_hooks.h | 412

[PATCH 1/4] LSM: Convert security_hook_heads into explicit array of struct list_head

2017-06-07 Thread Igor Stoppa
eads becomes a local variable. In order to pass 80 columns check by scripts/checkpatch.pl , rename security_hook_heads to hook_heads. Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Chris

[PATCH 2/4] Protectable Memory Allocator

2017-06-07 Thread Igor Stoppa
to support the protection of data that is initialized in sufficiently distinct phases. Signed-off-by: Igor Stoppa --- include/linux/page-flags.h | 2 + include/linux/pmalloc.h| 20 include/trace/events/mmflags.h | 1 + init/main.c| 2 + mm/Makefile

[PATCH 4/4] Make LSM Writable Hooks a command line option

2017-06-07 Thread Igor Stoppa
nvert security_hook_heads into explicit array of struct list_head" Author: Tetsuo Handa to break free from the static constraint imposed by the previous hardening model, based on __ro_after_init. The default value is disabled, unless SE Linux debugging is turned on. Signed-off-by: Igor Stoppa

[PATCH 3/4] Protectable Memory Allocator - Debug interface

2017-06-07 Thread Igor Stoppa
Debugfs interface: it creates the file /sys/kernel/debug/pmalloc/pools which exposes statistics about all the pools and memory nodes in use. Signed-off-by: Igor Stoppa --- mm/Kconfig | 11 ++ mm/pmalloc.c | 113 +++ 2 files

[PATCH 1/5] LSM: Convert security_hook_heads into explicit array of struct list_head

2017-06-05 Thread Igor Stoppa
eads becomes a local variable. In order to pass 80 columns check by scripts/checkpatch.pl , rename security_hook_heads to hook_heads. Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Chris

[no subject]

2017-06-05 Thread Igor Stoppa
is required. * I'll be AFK for about a week, so I preferred to share this version, even if not thoroughly tested, in the hope to get preliminary comments, but it is rough around the edges. Igor Stoppa (4): Protectable Memory Allocator Protectable Memory Allocator - Debug interface Make LSM

[PATCH 4/5] Make LSM Writable Hooks a command line option

2017-06-05 Thread Igor Stoppa
nvert security_hook_heads into explicit array of struct list_head" Author: Tetsuo Handa to break free from the static constraint imposed by the previous hardening model, based on __ro_after_init. Signed-off-by: Igor Stoppa CC: Tetsuo Handa --- init/main.c | 2 ++ security/secur

[PATCH 3/5] Protectable Memory Allocator - Debug interface

2017-06-05 Thread Igor Stoppa
Debugfs interface: it creates a file /sys/kernel/debug/pmalloc/pools which exposes statistics about all the pools and memory nodes in use. Signed-off-by: Igor Stoppa --- mm/Kconfig | 11 ++ mm/pmalloc.c | 113 +++ 2 files changed

[PATCH 2/5] Protectable Memory Allocator

2017-06-05 Thread Igor Stoppa
in sufficiently distinct phases. Signed-off-by: Igor Stoppa --- include/linux/page-flags.h | 2 + include/linux/pmalloc.h| 20 include/trace/events/mmflags.h | 1 + mm/Makefile| 2 +- mm/pmalloc.c | 227

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

2017-06-06 Thread Igor Stoppa
On 05/06/17 23:50, Tetsuo Handa wrote: > Casey Schaufler wrote: [...] >> I don't care for calling this "security debug". Making >> the lists writable after init isn't about development, >> it's about (Tetsuo's desire for) dynamic module loading. >> I would prefer "dynamic_module_lists" our

Re: [kernel-hardening] [PATCH 3/5] Protectable Memory Allocator - Debug interface

2017-06-06 Thread Igor Stoppa
On 05/06/17 23:24, Jann Horn wrote: > On Mon, Jun 5, 2017 at 9:22 PM, Igor Stoppa wrote: >> Debugfs interface: it creates a file [...] > You should probably be using %pK to hide the kernel pointers. ok, will do --- igor

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

2017-06-06 Thread Igor Stoppa
On 06/06/17 13:54, Tetsuo Handa wrote: [...] > "Loading modules which are not compiled as built-in" is correct. > My use case is to allow users to use LSM modules as loadable kernel > modules which distributors do not compile as built-in. Ok, so I suppose someone should eventually lock down the

Re: [PATCH 2/5] Protectable Memory Allocator

2017-06-06 Thread Igor Stoppa
On 06/06/17 09:25, Christoph Hellwig wrote: > On Tue, Jun 06, 2017 at 01:44:32PM +0900, Tetsuo Handa wrote: [..] >> As far as I know, not all CONFIG_MMU=y architectures provide >> set_memory_ro()/set_memory_rw(). You need to provide fallback for >> architectures which do not provide

Re: [PATCH 2/5] Protectable Memory Allocator

2017-06-06 Thread Igor Stoppa
Hi, thanks a lot for the review. My answers are in-line below. I have rearranged your comments because I wasn't sure how to reply to them inlined. On 06/06/17 07:44, Tetsuo Handa wrote: > Igor Stoppa wrote: [...] > As far as I know, not all CONFIG_MMU=y architectures provide > set_

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

2017-06-06 Thread Igor Stoppa
On 06/06/17 14:42, Tetsuo Handa wrote: > Igor Stoppa wrote: >> Who decides when enough is enough, meaning that all the needed modules >> are loaded? >> Should I provide an interface to user-space? A sysfs entry? > > No such interface is needed. Just an API

Re: [PATCH 2/5] Protectable Memory Allocator

2017-06-06 Thread Igor Stoppa
On 06/06/17 15:08, Tetsuo Handa wrote: > Igor Stoppa wrote: >>>> +struct pmalloc_node { >>>> + struct hlist_node nodes_list; >>>> + atomic_t used_words; >>>> + unsigned int total_words; >>>> + __PMALLOC_ALIGNED align_t data[];

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

2017-06-06 Thread Igor Stoppa
On 06/06/17 17:36, Tetsuo Handa wrote: > Igor Stoppa wrote: >> For the case at hand, would it work if there was a non-API call that you >> could use until the API is properly expanded? > > Kernel command line switching (i.e. this patch) is fine for my use cases. > &g

[RFC v5 PATCH 0/4] NOT FOR MERGE - ro protection for dynamic data

2017-06-06 Thread Igor Stoppa
sure): - need for specific __PMALLOC_ALIGNED ? - is it really needed to unprotect a pool? can't it wait for the implementation of write-seldom? Igor Stoppa (3): Protectable Memory Allocator Protectable Memory Allocator - Debug interface Make LSM Writable Hooks a command line option Tetsuo Han

[PATCH 1/4] LSM: Convert security_hook_heads into explicit array of struct list_head

2017-06-06 Thread Igor Stoppa
eads becomes a local variable. In order to pass 80 columns check by scripts/checkpatch.pl , rename security_hook_heads to hook_heads. Signed-off-by: Tetsuo Handa Cc: Kees Cook Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Schaufler Cc: James Morris Cc: Igor Stoppa Cc: Chris

[PATCH 2/4] Protectable Memory Allocator

2017-06-06 Thread Igor Stoppa
to support the protection of data that is initialized in sufficiently distinct phases. Signed-off-by: Igor Stoppa --- include/linux/page-flags.h | 2 + include/linux/pmalloc.h| 20 include/trace/events/mmflags.h | 1 + init/main.c| 2 + mm/Makefile

[PATCH 3/4] Protectable Memory Allocator - Debug interface

2017-06-06 Thread Igor Stoppa
Debugfs interface: it creates the file /sys/kernel/debug/pmalloc/pools which exposes statistics about all the pools and memory nodes in use. Signed-off-by: Igor Stoppa --- mm/Kconfig | 11 ++ mm/pmalloc.c | 113 +++ 2 files

[PATCH 4/4] Make LSM Writable Hooks a command line option

2017-06-06 Thread Igor Stoppa
nvert security_hook_heads into explicit array of struct list_head" Author: Tetsuo Handa to break free from the static constraint imposed by the previous hardening model, based on __ro_after_init. The default value is disabled, unless SE Linux debugging is turned on. Signed-off-by: Igor Stoppa

[PATCH 0/1] mm: Improve consistency of ___GFP_xxx masks

2017-04-26 Thread Igor Stoppa
The GFP bitmasks and the __GFP_BITS_SHIFT defines are expressed as hardcoded constants. This can be expressed in a more consistent way by relying on an enum of shift positions. Igor Stoppa (1): Remove hardcoding of ___GFP_xxx bitmasks include/linux/gfp.h | 82

[PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-26 Thread Igor Stoppa
The bitmasks used for ___GFP_xxx can be defined in terms of an enum, which doesn't require manual updates to its values. As bonus, __GFP_BITS_SHIFT is automatically kept consistent. Signed-off-by: Igor Stoppa --- include/linux/gfp.h | 82 +++-- 1

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-26 Thread Igor Stoppa
On 26/04/17 17:47, Michal Hocko wrote: > On Wed 26-04-17 16:35:49, Igor Stoppa wrote: >> The bitmasks used for ___GFP_xxx can be defined in terms of an enum, >> which doesn't require manual updates to its values. > > GFP masks are rarely updated so why is this worth

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-27 Thread Igor Stoppa
On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it,

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-27 Thread Igor Stoppa
On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it,

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-27 Thread Igor Stoppa
On 27/04/17 16:41, Michal Hocko wrote: > On Wed 26-04-17 18:29:08, Igor Stoppa wrote: > [...] >> If you prefer to have this patch only as part of the larger patchset, >> I'm also fine with it. > > I agree that the situation is not ideal. If a larger set of chan

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-28 Thread Igor Stoppa
On 28/04/17 10:40, Michal Hocko wrote: > Do not add a new zone, really. What you seem to be looking for is an > allocator on top of the page/memblock allocator which does write > protection on top. I understand that you would like to avoid object > management duplication but I am not really

Generic approach to customizable zones - was: Re: [PATCH v7 0/7] Introduce ZONE_CMA

2017-04-28 Thread Igor Stoppa
On 27/04/17 18:06, Michal Hocko wrote: > On Tue 25-04-17 12:42:57, Joonsoo Kim wrote: [...] >> Yes, it requires one more bit for a new zone and it's handled by the patch. > > I am pretty sure that you are aware that consuming new page flag bits > is usually a no-go and something we try to avoid

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

2017-04-28 Thread Igor Stoppa
On 28/04/17 10:43, Igor Stoppa wrote: [...] > I'm writing an alternative different proposal, let's call it last attempt. > > Should be ready in a few minutes. Here: http://marc.info/?l=linux-mm=149336675129967=2 -- thanks, igor

Re: Generic approach to customizable zones - was: Re: [PATCH v7 0/7] Introduce ZONE_CMA

2017-04-28 Thread Igor Stoppa
, but I have not completed the whole conversion. > On Fri 28-04-17 11:04:27, Igor Stoppa wrote: > [...] >> * if one is happy to have a 64bits type, allow for as many zones as >> it's possible to fit, or anyway more than what is possible with >> the 32 bit mask. > >

<    4   5   6   7   8   9