linux-kernel - Re: [PATCH v2] Moved module init-functions into the module.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1498152084.15628.1@ssh.steve.org.uk>
Date:   Thu, 22 Jun 2017 17:21:24 +0000
From:   Steve Kemp <steve@...ve.fi>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        James Morris <james.l.morris@...cle.com>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH v2] Moved module init-functions into the module.

> > The module initialization code belongs in the module.
> > The LSM infrastructure should have an absolute minimum
> > of module specific information. I would rather see the
> > "minor" modules (yama, loadpin) changed to use the module
> > registration scheme used by the "major" modules, but that
> > will require a mechanism to ensure module ordering, and
> > we don't have that yet. No, don't do this.
> 
> Yeah, I agree: initialization order is important here and I don't want
> to depend on the Makefile for this.

  I can appreciate that argument.  I did consider it myself,
 but decided that because the minor modules had such differing
 goals, and no real functional overlap, in practice that would
 mean that explicit ordering wasn't a strong requirement.

  If/when a better registration scheme becomes available then
 we'll all switch to using it, and that would be great.

  Thanks for the feedback.  I'll not tweak any further.

Steve
-- 
https://steve.fi/