[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1706010855410.20834@namei.org>
Date: Thu, 1 Jun 2017 08:56:18 +1000 (AEST)
From: James Morris <jmorris@...ei.org>
To: Igor Stoppa <igor.stoppa@...wei.com>
cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
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>,
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 Wed, 31 May 2017, Igor Stoppa wrote:
> On 30/05/17 13:32, James Morris wrote:
>
> > 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).
>
> I propose to take this patch as part of those I will be submitting.
> It took me some unplanned time to add support for hardened user copy,
> but now it's done - at least to a point that I can test it without failures.
>
> So I'm back on track to provide an example of the smalloc api and I can
> also use Tetsuo's work (thanks again, btw).
> This patch would be sandwiched between the smalloc ones and the LSM rework.
>
> It can get merged when the rest (hopefully) is merged.
>
> But I have a more prosaic question: since smalloc is affecting the
> memory subsystem, can it still be merged through the security tree?
It needs acks from the maintainers of the affected subsystems.
--
James Morris
<jmorris@...ei.org>
Powered by blists - more mailing lists