Re: Bug#485070: cryptsetup: "FATAL" padlock_{aes,sha} error during boot
Version: 3.7-pre2-1
On Sat, 2011-07-30 at 14:13 +0800, Herbert Xu wrote:
> Ralf Jung wrote:
> > Hi,
> >
> > as per request of Jonathan at http://bugs.debian.org/cgi-
> > bin/bugreport.cgi?bug=485070, I am reporting the mentioned bug to this list
> > as
> > well:
> >
> > With current Debian testing (Kernel 2.6.39), I am getting this error on
> > each
> > boot:
> > FATAL: Error inserting padlock_sha (/lib/modules/2.6.39-2-
> > amd64/kernel/drivers/crypto/padlock-sha.ko): No such device
> > I understand it is harmless, but it should still be fixed since it
> > irritates
> > users suggesting something is seriously going wrong.
>
> That message comes from user-space and needs to be fixed there.
Right, it comes from modprobe.
Fixed in module-init-tools version 3.5, commit
cdafffbadc5831ad56fe00ecd420ca9c36e9474f ("don't warn noisely if loading
multiple module aliases").
Ben.
signature.asc
Description: This is a digitally signed message part
[PATCH] crypto: padlock-aes - Make module loading even quieter when hardware is missing
When loading aes via the module alias, a padlock module failing to
load due to missing hardware is not particularly notable. With
v2.6.27-rc1~1107^2~14 (crypto: padlock - Make module loading quieter
when hardware isn't available, 2008-07-03), the padlock-aes module
suppresses the relevant messages when the "quiet" flag is in use; but
better to suppress this particular message completely, since the
administrator can already distinguish such errors by the absence of a
message indicating initialization failing or succeeding.
This avoids occasional messages in syslog of the form
padlock_aes: VIA PadLock not detected.
Signed-off-by: Jonathan Nieder
---
Herbert Xu wrote:
> Ralf Jung wrote:
>> With current Debian testing (Kernel 2.6.39), I am getting this error on each
>> boot:
>> FATAL: Error inserting padlock_sha (/lib/modules/2.6.39-2-
>> amd64/kernel/drivers/crypto/padlock-sha.ko): No such device
[...]
> That message comes from user-space and needs to be fixed there.
Thanks. Indeed, I was sloppy when reading the original report and
thought he was talking about a different message. Sorry for the
noise.
drivers/crypto/padlock-aes.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index db33d300..29b9469f 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -508,10 +508,8 @@ static int __init padlock_init(void)
int ret;
struct cpuinfo_x86 *c = &cpu_data(0);
- if (!cpu_has_xcrypt) {
- printk(KERN_NOTICE PFX "VIA PadLock not detected.\n");
+ if (!cpu_has_xcrypt)
return -ENODEV;
- }
if (!cpu_has_xcrypt_enabled) {
printk(KERN_NOTICE PFX "VIA PadLock detected, but not enabled.
Hmm, strange...\n");
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] crypto, sha1: export sha1_update for reuse
On Thu, Jul 28, 2011 at 05:29:35PM +0200, Mathias Krause wrote:
> On Thu, Jul 28, 2011 at 4:58 PM, Herbert Xu
> wrote:
> > On Sun, Jul 24, 2011 at 07:53:13PM +0200, Mathias Krause wrote:
> >>
> >> diff --git a/include/crypto/sha.h b/include/crypto/sha.h
> >> index 069e85b..7c46d0c 100644
> >> --- a/include/crypto/sha.h
> >> +++ b/include/crypto/sha.h
> >> @@ -82,4 +82,9 @@ struct sha512_state {
> >> u8 buf[SHA512_BLOCK_SIZE];
> >> };
> >>
> >> +#if defined(CONFIG_CRYPTO_SHA1) || defined (CONFIG_CRYPTO_SHA1_MODULE)
> >> +extern int crypto_sha1_update(struct shash_desc *desc, const u8 *data,
> >> + unsigned int len);
> >> +#endif
> >
> > Please remove the unnecessary #if.
>
> The function will only be available when crypto/sha1_generic.o will
> either be build into the kernel or build as a module. Without the #if
> a potential wrong user of this function might not be detected as early
> as at compilation time but as late as at link time, or even worse, as
> late as on module load time -- which is pretty bad. IMHO it's better
> to detect errors early, as in reading "error: implicit declaration of
> function ‘crypto_sha1_update’" when trying to compile the code in
> question instead of "Unknown symbol crypto_sha1_update" in dmesg when
> trying to load the module. That for I would like to keep the #if.
In order to be consistent please remove the ifdef. In most
similar cases in the crypto subsystem we don't do this. As
adding such ifdefs all over the place would gain very little,
I'd much rather you left it out.
The one case where this would make sense is if it were a trivial
inline in the !defined case.
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
