From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751184AbdE3KdI (ORCPT ); Tue, 30 May 2017 06:33:08 -0400 Received: from namei.org ([65.99.196.166]:52985 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750904AbdE3KdH (ORCPT ); Tue, 30 May 2017 06:33:07 -0400 Date: Tue, 30 May 2017 20:32:02 +1000 (AEST) From: James Morris To: Tetsuo Handa cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Casey Schaufler , Christoph Hellwig , Igor Stoppa , James Morris , Kees Cook , Paul Moore , Stephen Smalley Subject: Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head In-Reply-To: <1496003387-3184-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> Message-ID: References: <1495883858-3336-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <1496003387-3184-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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