linux-kernel - linux-next: manual merge of the efi-lock-down tree with the modules tree

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

Message-ID: <20180417113218.4e6ba307@canb.auug.org.au>
Date:   Tue, 17 Apr 2018 11:32:18 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     David Howells <dhowells@...hat.com>, Jessica Yu <jeyu@...nel.org>
Cc:     Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jia Zhang <zhang.jia@...ux.alibaba.com>
Subject: linux-next: manual merge of the efi-lock-down tree with the modules
 tree

Hi David,

Today's linux-next merge of the efi-lock-down tree got a conflict in:

  kernel/module.c

between commit:

  2c8fd268f418 ("module: Do not access sig_enforce directly")

from the modules tree and commit:

  7c0d4949d834 ("Enforce module signatures if the kernel is locked down")

from the efi-lock-down tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/module.c
index 1e3337bcf1e7,62419cf48ef6..000000000000
--- a/kernel/module.c
+++ b/kernel/module.c
@@@ -2777,19 -2786,46 +2780,46 @@@ static int module_sig_check(struct load
  		err = mod_verify_sig(mod, &info->len);
  	}
  
- 	if (!err) {
+ 	switch (err) {
+ 	case 0:
  		info->sig_ok = true;
  		return 0;
- 	}
  
- 	/* Not having a signature is only an error if we're strict. */
- 	if (err == -ENOKEY && !is_module_sig_enforced())
- 		err = 0;
+ 		/* We don't permit modules to be loaded into trusted kernels
+ 		 * without a valid signature on them, but if we're not
+ 		 * enforcing, certain errors are non-fatal.
+ 		 */
+ 	case -ENODATA:
+ 		reason = "Loading of unsigned module";
+ 		goto decide;
+ 	case -ENOPKG:
+ 		reason = "Loading of module with unsupported crypto";
+ 		goto decide;
+ 	case -ENOKEY:
+ 		reason = "Loading of module with unavailable key";
+ 	decide:
 -		if (sig_enforce) {
++		if (is_module_sig_enforced()) {
+ 			pr_notice("%s is rejected\n", reason);
+ 			return -EKEYREJECTED;
+ 		}
  
- 	return err;
+ 		if (can_do_ima_check && is_ima_appraise_enabled())
+ 			return 0;
+ 		if (kernel_is_locked_down(reason))
+ 			return -EPERM;
+ 		return 0;
+ 
+ 		/* All other errors are fatal, including nomem, unparseable
+ 		 * signatures and signature check failures - even if signatures
+ 		 * aren't required.
+ 		 */
+ 	default:
+ 		return err;
+ 	}
  }
  #else /* !CONFIG_MODULE_SIG */
- static int module_sig_check(struct load_info *info, int flags)
+ static int module_sig_check(struct load_info *info, int flags,
+ 			    bool can_do_ima_check)
  {
  	return 0;
  }

Content of type "application/pgp-signature" skipped