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
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).
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 all
On 5/28/2017 1:29 PM, Tetsuo Handa wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountere
On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven'
Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hoo
6 matches
Mail list logo