linux-kernel - Re: [PATCH] init/main.c: Initialize early LSMs after arch code

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhQ1JOJD6Eqvcn98UanH5e+s6wJ4qwWEdym4_ycm+vfxmQ@mail.gmail.com>
Date: Wed, 7 Aug 2024 19:43:59 -0400
From: Paul Moore <paul@...l-moore.com>
To: KP Singh <kpsingh@...nel.org>
Cc: Nathan Chancellor <nathan@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, bp@...en8.de, sfr@...b.auug.org.au, 
	peterz@...radead.org, Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH] init/main.c: Initialize early LSMs after arch code

On Wed, Aug 7, 2024 at 6:45 PM KP Singh <kpsingh@...nel.org> wrote:
> On Wed, Aug 7, 2024 at 10:45 PM Paul Moore <paul@...l-moore.com> wrote:
> > On Tue, Aug 6, 2024 at 5:41 PM Paul Moore <paul@...l-moore.com> wrote:
> > > On Mon, Aug 5, 2024 at 10:20 PM Nathan Chancellor <nathan@...nel.org> wrote:
> >
> > ...
> >
> > > > For what it's worth, I have not noticed any issues in my -next testing
> > > > with this patch applied but I only build architectures that build with
> > > > LLVM due to the nature of my work. If exposure to more architectures is
> > > > desirable, perhaps Guenter Roeck would not mind testing it with his
> > > > matrix?
> > >
> > > Thanks Nathan.
> > >
> > > I think the additional testing would be great, KP can you please work
> > > with Guenter to set this up?
> >
>
> Adding Guenter directly to this thread.
>
> > Is that something you can do KP?  I'm asking because I'm looking at
> > merging some other patches into lsm/dev and I need to make a decision
> > about the static call patches (hold off on merging the other patches
> > until the static call testing is complete, or yank the static call
> > patches until testing is complete and then re-merge).  Understanding
> > your ability to do the additional testing, and a rough idea of how
>
> I have done the best of the testing I could do here. I think we should
> let this run its normal course and see if this breaks anything. I am
> not sure how testing is done before patches are merged and what else
> you expect me to do?

That is why I was asking you to get in touch with Guenter to try and
sort out what needs to be done to test this across different
architectures.

With all due respect, this patchset has a history of not being as
tested as well as I would like; we had the compilation warning on gcc
and then the linux-next breakage.  The gcc problem wasn't a major
problem (although it was disappointing, especially considering the
context around it), but I consider the linux-next breakage fairly
serious and would like to have some assurance beyond your "it's okay,
trust me" this time around.  If there really is no way to practically
test this patchset across multiple arches prior to throwing it into
linux-next, so be it, but I want to see at least some effort towards
trying to make that happen.

-- 
paul-moore.com