|
Message-ID: <alpine.LRH.2.20.1705302025110.31018@namei.org> Date: Tue, 30 May 2017 20:32:02 +1000 (AEST) From: James Morris <jmorris@...ei.org> To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, Casey Schaufler <casey@...aufler-ca.com>, Christoph Hellwig <hch@...radead.org>, Igor Stoppa <igor.stoppa@...wei.com>, James Morris <james.l.morris@...cle.com>, Kees Cook <keescook@...omium.org>, Paul Moore <paul@...l-moore.com>, Stephen Smalley <sds@...ho.nsa.gov> Subject: Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head On Mon, 29 May 2017, Tetsuo Handa wrote: > Igor proposed a sealable memory allocator, and the LSM hooks > ("struct security_hook_heads security_hook_heads" and > "struct security_hook_list ...[]") will benefit from that allocator via > protection using set_memory_ro()/set_memory_rw(), and that allocator > will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will > likely be moving to that direction. > > This means that these structures will be allocated at run time using > that allocator, and therefore the address of these structures will be > determined at run time rather than compile time. > > But currently, LSM_HOOK_INIT() macro depends on the address of > security_hook_heads being known at compile time. If we use an enum > so that LSM_HOOK_INIT() macro does not need to know absolute address of > security_hook_heads, it will help us to use that allocator for LSM hooks. > This seems like pointless churn in security-critical code in anticipation of features which are still in development and may not be adopted. Is there a compelling reason to merge this now? (And I don't mean worrying about non-existent compliers). -- James Morris <jmorris@...ei.org>
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.