Re: linux-next: Tree for Dec 14 (security/integrity/ima/)

[Paul Gortmaker]

[Re: linux-next: Tree for Dec 14 (security/integrity/ima/)] On 14/12/2018 (Fri 15:26) Paul Gortmaker wrote:

> [Re: linux-next: Tree for Dec 14 (security/integrity/ima/)] On 14/12/2018 (Fri 14:19) Mimi Zohar wrote:
> 
> > On Fri, 2018-12-14 at 08:25 -0800, Randy Dunlap wrote:
> > > 
> > > on i386:
> > > 
> > >   CC      security/integrity/ima/ima_main.o
> > > ../security/integrity/ima/ima_main.c: In function 'ima_load_data':
> > > ../security/integrity/ima/ima_main.c:535:3: error: implicit declaration of function 'is_module_sig_enforced' [-Werror=implicit-function-declaration]
> > >    sig_enforce = is_module_sig_enforced();
> > >    ^

[...]

> > Commit 4f83d5ea643a ("security: integrity: make ima_main explicitly
> > non-modular") just removed module.h.
> 
> Yes, unfortunately the security directory has additional confusion
> because there is name space overlap between "module" as used in Linux
> Security Module, and "module" as in "insmod foo.ko".  The ima_main
> is not modular, but it does use modular infrastructure to load others.
> 
> Fortunately this was the final commit in the series, so it can be
> removed or reverted as per maintainer's choice.  In the meantime, I'll
> look into why my "allyesconfig" build testing didn't pick up on this,
> so I can close that testing gap.

I've confirmed that most .config result in an implicit header presence
by looking at the CPP output.  Details below.

James, if your input branch to linux-next is strictly fast forward, here
is a partial revert to fix up what Randy found that you can apply.

Thanks for the report, and again - sorry for not detecting this myself.
Paul.
--