[PATCH 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag.

[Nikos Mavrogiannopoulos]

The added CRYPTO_ALG_KERN_DRIVER_ONLY flag indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.

Signed-off-by: Nikos Mavrogiannopoulos n...@gnutls.org
---
 drivers/crypto/geode-aes.c|8 --
 drivers/crypto/hifn_795x.c|3 +-
 drivers/crypto/ixp4xx_crypto.c|2 +
 drivers/crypto/mv_cesa.c  |   12 ++---
 drivers/crypto/n2_core.c  |7 -
 drivers/crypto/omap-aes.c |8 -
 drivers/crypto/omap-sham.c|4 +++
 drivers/crypto/picoxcell_crypto.c |   46 +++
 drivers/crypto/s5p-sss.c  |6 +++-
 drivers/crypto/talitos.c  |   48 ++--
 include/linux/crypto.h|5 
 11 files changed, 110 insertions(+), 39 deletions(-)

diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 219d09c..8b0ef70 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -392,8 +392,9 @@ static struct crypto_alg geode_cbc_alg = {
.cra_name   =   cbc(aes),
.cra_driver_name=   cbc-aes-geode,
.cra_priority   =   400,
-   .cra_flags  =   CRYPTO_ALG_TYPE_BLKCIPHER |
-   
CRYPTO_ALG_NEED_FALLBACK,
+   .cra_flags  =   CRYPTO_ALG_TYPE_BLKCIPHER |
+   CRYPTO_ALG_KERN_DRIVER_ONLY |
+   CRYPTO_ALG_NEED_FALLBACK,
.cra_init   =   fallback_init_blk,
.cra_exit   =   fallback_exit_blk,
.cra_blocksize  =   AES_MIN_BLOCK_SIZE,
@@ -479,7 +480,8 @@ static struct crypto_alg geode_ecb_alg = {
.cra_driver_name=   ecb-aes-geode,
.cra_priority   =   400,
.cra_flags  =   CRYPTO_ALG_TYPE_BLKCIPHER |
-   
CRYPTO_ALG_NEED_FALLBACK,
+   CRYPTO_ALG_KERN_DRIVER_ONLY |
+   CRYPTO_ALG_NEED_FALLBACK,
.cra_init   =   fallback_init_blk,
.cra_exit   =   fallback_exit_blk,
.cra_blocksize  =   AES_MIN_BLOCK_SIZE,
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index fe765f4..14780c8 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2494,7 +2494,8 @@ static int hifn_alg_alloc(struct hifn_device *dev, struct 
hifn_alg_template *t)
 t-drv_name, dev-name);
 
alg-alg.cra_priority = 300;
-   alg-alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC;
+   alg-alg.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+   CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC;
alg-alg.cra_blocksize = t-bsize;
alg-alg.cra_ctxsize = sizeof(struct hifn_context);
alg-alg.cra_alignmask = 0;
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 4c20c5b..a82c11a 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1449,6 +1449,7 @@ static int __init ixp_module_init(void)
/* block ciphers */
cra-cra_type = crypto_ablkcipher_type;
cra-cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
 CRYPTO_ALG_ASYNC;
if (!cra-cra_ablkcipher.setkey)
cra-cra_ablkcipher.setkey = ablk_setkey;
@@ -1461,6 +1462,7 @@ static int __init ixp_module_init(void)
/* authenc */
cra-cra_type = crypto_aead_type;
cra-cra_flags = CRYPTO_ALG_TYPE_AEAD |
+CRYPTO_ALG_KERN_DRIVER_ONLY |
 CRYPTO_ALG_ASYNC;
cra-cra_aead.setkey = aead_setkey;
cra-cra_aead.setauthsize = aead_setauthsize;
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 38a3297..04f47e5 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -897,7 +897,8 @@ struct crypto_alg mv_aes_alg_ecb = {
.cra_name   = ecb(aes),
.cra_driver_name= mv-ecb-aes,
.cra_priority   = 300,
-   .cra_flags  = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_flags  = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
.cra_blocksize  = 16,

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

[David Howells]

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?

 But I need to know exactly what these version-dependent mangling of
 modules is.  Is it real?  Is it more than strip?  Is it so hard to fix
 that it makes sense to add 450 lines of dense kernel code to allow
 alteration of a module after signing?

The strip program (as far as I know that's the only binutil that we need worry
about) rearranges and reorders the section, symbol and relocation tables when
it discards stuff, and different versions of strip have done it differently.

There's GNU build ID.  gcc/binutils was changed at some point to insert an ELF
note with the time at which the binary was built (something to do with
debuginfo matching, I think), and strip would update this when run on the
binary.

I haven't encountered many other things introducing breakage that wasn't the
fault of the tool doing the breaking - which usually got fixed pretty quickly.


However, you said it should be fairly easy to jump over the ELF parcel to get
to the signature.  How do you plan on doing that?  I presume you would just
parse sufficient of the ELF to find the theoretical ELF EOF and then look there
for a whole string of signatures - and hope they haven't got removed by some
unanticipated tool before you see the module.

David
--
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: RFC: redesigning random(4)

[Sandy Harris]

On Thu, Sep 29, 2011 at 2:46 PM, Sandy Harris sandyinch...@gmail.com wrote:

 I have been thinking about how random(4) might be redesigned ...

 ... make the input
 pool use Skein (or another SHA-3 candidate) and the output pools a
 modified counter-mode AES.

I now actually have most of the code for that and a substantial
rationale document, both in a first draft sort of state.

I have worked out how to use a block cipher in a way that has
the hard-to-invert property and does not either lose state when
it rekeys or encrypt successive counter values with a small
Hamming difference. It is fairly complex.

 Currently the driver uses SHA-1 for all three. ,,,

Having looked at the block cipher method in some detail, I've now
concluded that it is better to just use a hash which is non-invertible
by design and does not make analysis more difficult.

I may eventually have code  rationale for that too, but almost
certainly not soon.
--
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