Duplicated module names

Lucas De Marchi writes: > Hi! > > CC'ing Rusty and mailing lists Thanks. > Rusty and ohers: it looks like both CONFIG_CRC32 and > CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate > modules with the same name, crc32. Could that be fixed? Gah. Looks

Re: crypto: api - Move module sig ifdef into accessor function

Herbert Xu herb...@gondor.apana.org.au writes: Currently we're hiding mod-sig_ok under an ifdef in open code. This patch adds a module_sig_ok accessor function and removes that ifdef. Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Herbert Xu herb...@gondor.apana.org.au Did you

Re: [PATCH 3/5] hwrng: core - Do not register device opportunistically

Herbert Xu herb...@gondor.apana.org.au writes: Currently we only register the device when a valid RNG is added. However the way it's done is buggy because we test whether there is a current RNG to determine whether we need to register. As the current RNG may be missing due to a

Re: [PATCH 1/5] hwrng: core - Use struct completion for cleanup_done

Herbert Xu herb...@gondor.apana.org.au writes: There is no point in doing a manual completion for cleanup_done when struct completion fits in perfectly. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au Indeed. Acked-by: Rusty Russell ru...@rustcorp.com.au Thanks, Rusty

Re: [PATCH 2/5] hwrng: core - Fix current_rng init/cleanup race yet again

Herbert Xu herb...@gondor.apana.org.au writes: The kref solution is still buggy because we were only focusing on the register/unregister race. The same race affects the setting of current_rng through sysfs. This patch fixes it by using kref_get_unless_zero. Signed-off-by: Herbert Xu

Re: [PATCH] crypto: Add soft module dependency to load HW accelerated crypto modules

Tim Chen tim.c.c...@linux.intel.com writes: On Fri, 2014-02-14 at 15:28 -0500, Neil Horman wrote: On Fri, Feb 14, 2014 at 11:14:37AM -0800, Tim Chen wrote: We added the soft module dependency of various crypto algorithm's module alias to generic crypto algorithm's module. This loads

Re: [PATCH] modules: add support for soft module dependencies

Lucas De Marchi lucas.demar...@profusion.mobi writes: On Tue, Sep 17, 2013 at 11:10 PM, Rusty Russell ru...@rustcorp.com.au wrote: Lucas De Marchi lucas.de.mar...@gmail.com writes: On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell ru...@rustcorp.com.au wrote: I'm happy to change this macro

Re: [PATCH] modules: add support for soft module dependencies

Lucas De Marchi lucas.de.mar...@gmail.com writes: On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu herb...@gondor.apana.org.au wrote: On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote: Herbert Xu herb...@gondor.apana.org.au writes: Hi Rusty: I don't know why this patch never went

Re: [BUG] 3.11 boot failure caused by commit crypto

Tim Chen tim.c.c...@linux.intel.com writes: On Tue, 2013-07-30 at 09:08 +1000, Herbert Xu wrote: On Mon, Jul 29, 2013 at 01:39:06PM -0700, Tim Chen wrote: Herbert, what are your thoughts on a proper fix to initrd issue for crct10dif modules not getting included? Or can we let the config

Re: [BUG] 3.11 boot failure caused by commit crypto

Herbert Xu herb...@gondor.apana.org.au writes: On Tue, Jul 30, 2013 at 03:26:50PM +0930, Rusty Russell wrote: Does this imply that you want me to push that to Linus now, and/or CC stable? Was planning for *next* merge window... Next merge window is fine. However, it would be good

Re: [PATCH RESEND/V2] crypto: Ignore validity dates of X.509 certificates at loading/parsing time

Alexander Holler hol...@ahsoftware.de writes: Am 02.05.2013 16:09, schrieb Alexander Holler: I don't see any real use case where checking the validity dates of X.509 certificates at parsing time adds any security gain. In contrast, doing so makes MODSIGN unusable on systems without a RTC (or

Re: [PULL] modules

Linus Torvalds torva...@linux-foundation.org writes: On Wed, Oct 10, 2012 at 2:57 AM, Rusty Russell ru...@rustcorp.com.au wrote: module signing is the highlight, but it's an all-over David Howells frenzy

[PULL] modules

Dunlap (1): asymmetric keys: fix printk format warning Rusty Russell (4): module: fix symbol waiting when module fails before init module: wait when loading a module which is currently initializing. module: signature checking hook MODSIGN: Make mrproper should remove

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Rusty Russell ru...@rustcorp.com.au wrote: Right. I think we need to use different names for generated vs supplied files The problem with supplied files is people who do allyesconfig, allmodconfig and randconfig just to test things finding

Re: [PATCH -next] asymmetric keys: fix printk format warning

Stephen Rothwell s...@canb.auug.org.au writes: [Lets also cc Rusty who committed the patch ...] On Wed, 03 Oct 2012 16:04:46 -0700 Randy Dunlap rdun...@xenotime.net wrote: From: Randy Dunlap rdun...@xenotime.net Fix printk format warning in x509_cert_parser.c:

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Rusty Russell ru...@rustcorp.com.au wrote: I noticed the Cert number didn't change with rebuilds: distclean didn't remove some files: $ git clean -f -f -x -d Removing extra_certificates Removing signing_key.priv Removing signing_key.x509

Re: [PATCH 1/2] modsign: don't use bashism in sh scripts.

David Howells dhowe...@redhat.com writes: Rusty Russell ru...@rustcorp.com.au wrote: -source ./.config +. ./.config Does that make a difference? It does on Ubuntu, where /bin/sh = dash. source is a bashism. Cheers, Rusty. -- To unsubscribe from this list: send the line

Re: [GIT PULL] Asymmetric keys and module signing

Josh Boyer jwbo...@redhat.com writes: On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote: Rusty Russell ru...@rustcorp.com.au wrote: [2.808075] Loading module verification certificates [2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Rusty Russell ru...@rustcorp.com.au wrote: And after those three fixes, I still get all fail: [3.361036] Request for unknown module key 'Magrathea: Glacier signing key: 6 e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11 Can you look back

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Hi Rusty, Could you pull my tree? And after those three fixes, I still get all fail: [3.361036] Request for unknown module key 'Magrathea: Glacier signing key: 6 e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Hi Rusty, Could you pull my tree? David --- The following changes since commit eeea3ac912207dcf759b95b2b4c36f96bce583bf: Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-09-06 10:23:58 -0700)

[PATCH 1/2] modsign: don't use bashism in sh scripts.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/scripts/sign-file b/scripts/sign-file index 1a472bb..e58e34e 100644 --- a/scripts/sign-file +++ b/scripts/sign-file @@ -10,7 +10,7 @@ scripts=`dirname $0` CONFIG_MODULE_SIG_SHA512=y if [ -r .config ] then -source ./.config

[PATCH 2/2] modules: don't call eu-strip if it doesn't exist.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost index 90b1bb1..2a4d1a1 100644 --- a/scripts/Makefile.modpost +++ b/scripts/Makefile.modpost @@ -165,11 +165,13 @@ endif # We strip the module as best we can - note that using

Re: [GIT PULL] Asymmetric keys and module signing

Mimi Zohar zo...@linux.vnet.ibm.com writes: On Wed, 2012-09-26 at 13:16 +0930, Rusty Russell wrote: David Howells dhowe...@redhat.com writes: The module signing patches provide: - Some fixes to Rusty's patch. Also an additional patch to extend the policy handling for modules

Re: [GIT PULL] Asymmetric keys and module signing

David Howells dhowe...@redhat.com writes: Rusty Russell ru...@rustcorp.com.au wrote: We do a very simple search for a particular string appended to the module (which is cache-hot and about to be SHA'd anyway). There's both a config option and a boot parameter which control whether we accept

Re: [GIT PULL] Asymmetric keys and module signing

); if (err == -ENOKEY !sig_enforce) err = 0; return err; In preparation, I've changed that below (and also, fixed up the -ENOKEY which I said I'd do, and didn't). Thanks, Rusty. PS. Agree with Kconfig options move, but I'll do that in separate patch. From: Rusty Russell

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Thu, 15 Dec 2011 00:14:31 +, David Howells dhowe...@redhat.com wrote: Rusty Russell ru...@ozlabs.org wrote: We can have false positives, but at worst that make us report EINVAL (bad signature) instead of ENOENT (no signature). EKEYREJECTED please; that way it's the same

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Mon, 12 Dec 2011 16:11:27 +, David Howells dhowe...@redhat.com wrote: Rusty Russell ru...@ozlabs.org wrote: OK, then you need to generate stripped modules as part of the build, too. It's a bit of a pain, sure, but hardly a showstopper. They'd have to be maximally stripped so

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Mon, 12 Dec 2011 01:21:40 +, David Howells dhowe...@redhat.com wrote: Rusty Russell ru...@ozlabs.org wrote: I think you misunderstand, I'm talking about the modinfo command, not the .modinfo section. Sorry, yes. But why do you need to enhance modinfo? I was suggesting that you

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Sat, 10 Dec 2011 10:37:23 -0800, Arjan van de Ven ar...@infradead.org wrote: Yes, there may be more than stripped and unstripped. You may need to do fancy things. But now, adding a signature is so easy that it's not a real problem. And we can always have a hook, like:

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Sat, 10 Dec 2011 14:08:34 +, David Howells dhowe...@redhat.com wrote: Rusty Russell ru...@ozlabs.org wrote: Sure, you now need to re-append that after stripping, but that's not the kernel's problem. You may also have to remove the signature before passing it to any

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Fri, 02 Dec 2011 18:46:51 +, David Howells dhowe...@redhat.com wrote: Signed modules may be safely stripped as the signature only covers those parts of the module the kernel actually uses and any ELF metadata required to deal with them. Any necessary ELF metadata that is affected by

Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Fri, 09 Dec 2011 18:43:26 +, David Howells dhowe...@redhat.com wrote: Rusty Russell ru...@ozlabs.org wrote: And adds a great deal of code in a supposedly security-sensitive path to achieve it. How about simply append a signature to the module? That'd be about 20 lines of code

Re: Fixing gave up waiting for init of module libcrc32c.

On Thu, 1 Apr 2010 05:33:51 am Brandon Philips wrote: On 09:36 Tue 30 Mar 2010, Rusty Russell wrote: The real fix here is to drop the lock, like Brandon suggested, but we need to do it more carefully: when we re-acquire the lock we need to re-lookup the symbol in case the module has

Re: Fixing gave up waiting for init of module libcrc32c.

-by: Brandon Philips bran...@ifup.org Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/kernel/module.c b/kernel/module.c --- a/kernel/module.c +++ b/kernel/module.c @@ -510,33 +510,25 @@ int use_module(struct module *a, struct struct module_use *use; int no_warn, err