Skip to contentSkip to conversation

display cipher details in sysfs

cryptoapi/sysfs In review Andreas Happe 6 participants 25 messages Sep 1, 2004 – Sep 29, 2004 2 messages not in the archive Crypto API

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): Xine.LNX.4.44.0409010043020.30561-100000@thoron.boston.redhat.com

Andreas Happe

author
#2 lore raw

Hi,

following-up to: James Morris <[email protected]> [040901 09:35]:

Quoted 4 lines

This looks potentially useful, although I'm not sure yet whether the userland crypto API should be exposed via sysfs or a separate filesystem.

I suggest you post the patch to linux-kernel and the crypto API list at:
http://lists.logix.cz/pipermail/cryptoapi as an RFC, for wider feedback.

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie which includes all information which is currently offered by /proc/crypto. This was done by embedding a kobject in struct crypto_alg (include/linux/crypto.h) and using a kset/subsystem instead of the currently used list (crypto_alg->cra_list was removed, as it shouldn't be needed anymore). crypto/proc.c was converted to use the subsystem internal rwlock/list for its iteration of ciphers.

I think that the place for the cryptoapi-tree in sysfs is wrong (but the others (block, module, bus, class, etc.) seemed worse). But the effort to change this should be neglectable (and centered at syfs.c).

Also the different cipher types (digest, compress..) could be seperated into own ksets/directories, but this would make the crypto/proc.c code worse.

small example:

| bash-2.05b# cd /sys/cryptoapi/
| bash-2.05b# ls
| aes  blowfish  cipher_null  compress_null  deflate  des  des3_ede
| digest_null  md5  serpent  sha1  sha256  twofish
| bash-2.05b# cd aes/
| bash-2.05b# ls
| blocksize  maxkeysize  minkeysize  module  name  type
| bash-2.05b# cat blocksize | 16
| bash-2.05b# cd ./../sha1/
| bash-2.05b# ls
| digestsize  module  name  type
| bash-2.05b# cat digestsize | 20
| bash-2.05b# cat type | digest

--Andreas

arch/i386/crypto/aes.c +0 -1
diff -u -N -r linux-2.6.9-rc1/arch/i386/crypto/aes.c linux-2.6.9-rc1-sys2/arch/i386/crypto/aes.c
@@ -488,7 +488,6 @@
 	.cra_blocksize		=	AES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct aes_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(aes_alg.cra_list),
 	.cra_u			=	{
 		.cipher = {
 			.cia_min_keysize	=	AES_MIN_KEY_SIZE,
crypto/aes.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/aes.c linux-2.6.9-rc1-sys2/crypto/aes.c
@@ -437,7 +437,6 @@
 	.cra_blocksize		=	AES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct aes_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(aes_alg.cra_list),
 	.cra_u			=	{
 		.cipher = {
 			.cia_min_keysize	=	AES_MIN_KEY_SIZE,
crypto/api.c +58 -41

144 lines not on this page · raw message

crypto/arc4.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/arc4.c linux-2.6.9-rc1-sys2/crypto/arc4.c
@@ -75,7 +75,6 @@
 	.cra_blocksize		=	ARC4_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct arc4_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(arc4_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	ARC4_MIN_KEY_SIZE,
 	.cia_max_keysize	=	ARC4_MAX_KEY_SIZE,
crypto/blowfish.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/blowfish.c linux-2.6.9-rc1-sys2/crypto/blowfish.c
@@ -452,7 +452,6 @@
 	.cra_blocksize		=	BF_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct bf_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	BF_MIN_KEY_SIZE,
 	.cia_max_keysize	=	BF_MAX_KEY_SIZE,
crypto/cast5.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/cast5.c linux-2.6.9-rc1-sys2/crypto/cast5.c
@@ -821,7 +821,6 @@
 	.cra_blocksize 	= CAST5_BLOCK_SIZE,
 	.cra_ctxsize 	= sizeof(struct cast5_ctx),
 	.cra_module 	= THIS_MODULE,
-	.cra_list 	= LIST_HEAD_INIT(alg.cra_list),
 	.cra_u 		= {
 		.cipher = {
 			.cia_min_keysize = CAST5_MIN_KEY_SIZE,
crypto/cast6.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/cast6.c linux-2.6.9-rc1-sys2/crypto/cast6.c
@@ -534,7 +534,6 @@
 	.cra_blocksize = CAST6_BLOCK_SIZE,
 	.cra_ctxsize = sizeof(struct cast6_ctx),
 	.cra_module = THIS_MODULE,
-	.cra_list = LIST_HEAD_INIT(alg.cra_list),
 	.cra_u = {
 		  .cipher = {
 			     .cia_min_keysize = CAST6_MIN_KEY_SIZE,
crypto/crc32c.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/crc32c.c linux-2.6.9-rc1-sys2/crypto/crc32c.c
@@ -80,7 +80,6 @@
 	.cra_blocksize	=	CHKSUM_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct chksum_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list	=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{
 		.digest = {
 			 .dia_digestsize=	CHKSUM_DIGEST_SIZE,
crypto/crypto_null.c +0 -3
diff -u -N -r linux-2.6.9-rc1/crypto/crypto_null.c linux-2.6.9-rc1-sys2/crypto/crypto_null.c
@@ -59,7 +59,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=       LIST_HEAD_INIT(compress_null.cra_list),
 	.cra_u			=	{ .compress = {
 	.coa_compress 		=	null_compress,
 	.coa_decompress		=	null_decompress } }

@@ -71,7 +70,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=       LIST_HEAD_INIT(digest_null.cra_list),	
 	.cra_u			=	{ .digest = {
 	.dia_digestsize		=	NULL_DIGEST_SIZE,
 	.dia_init   		=	null_init,

@@ -85,7 +83,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(cipher_null.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	NULL_KEY_SIZE,
 	.cia_max_keysize	=	NULL_KEY_SIZE,
crypto/deflate.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/deflate.c linux-2.6.9-rc1-sys2/crypto/deflate.c
@@ -196,7 +196,6 @@
 	.cra_flags		= CRYPTO_ALG_TYPE_COMPRESS,
 	.cra_ctxsize		= sizeof(struct deflate_ctx),
 	.cra_module		= THIS_MODULE,
-	.cra_list		= LIST_HEAD_INIT(alg.cra_list),
 	.cra_u			= { .compress = {
 	.coa_init		= deflate_init,
 	.coa_exit		= deflate_exit,
crypto/des.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/des.c linux-2.6.9-rc1-sys2/crypto/des.c
@@ -1245,7 +1245,6 @@
 	.cra_blocksize		=	DES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct des_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(des_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	DES_KEY_SIZE,
 	.cia_max_keysize	=	DES_KEY_SIZE,

@@ -1260,7 +1259,6 @@
 	.cra_blocksize		=	DES3_EDE_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct des3_ede_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(des3_ede_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	DES3_EDE_KEY_SIZE,
 	.cia_max_keysize	=	DES3_EDE_KEY_SIZE,
crypto/khazad.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/khazad.c linux-2.6.9-rc1-sys2/crypto/khazad.c
@@ -885,7 +885,6 @@
 	.cra_blocksize		=	KHAZAD_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct khazad_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(khazad_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	KHAZAD_KEY_SIZE,
 	.cia_max_keysize	=	KHAZAD_KEY_SIZE,
crypto/Makefile +2 -1
diff -u -N -r linux-2.6.9-rc1/crypto/Makefile linux-2.6.9-rc1-sys2/crypto/Makefile
@@ -3,9 +3,10 @@
 #
 
 proc-crypto-$(CONFIG_PROC_FS) = proc.o
+sysfs-crypto-$(CONFIG_SYSFS) = sysfs.o
 
 obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
-			$(proc-crypto-y)
+			$(proc-crypto-y) $(sysfs-crypto-y)
 
 obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
 obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
crypto/md4.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/md4.c linux-2.6.9-rc1-sys2/crypto/md4.c
@@ -224,7 +224,6 @@
 	.cra_blocksize	=	MD4_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct md4_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),	
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	MD4_DIGEST_SIZE,
 	.dia_init   	= 	md4_init,
crypto/md5.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/md5.c linux-2.6.9-rc1-sys2/crypto/md5.c
@@ -219,7 +219,6 @@
 	.cra_blocksize	=	MD5_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct md5_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list	=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	MD5_DIGEST_SIZE,
 	.dia_init   	= 	md5_init,
crypto/michael_mic.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/michael_mic.c linux-2.6.9-rc1-sys2/crypto/michael_mic.c
@@ -163,7 +163,6 @@
 	.cra_blocksize	= 8,
 	.cra_ctxsize	= sizeof(struct michael_mic_ctx),
 	.cra_module	= THIS_MODULE,
-	.cra_list	= LIST_HEAD_INIT(michael_mic_alg.cra_list),
 	.cra_u		= { .digest = {
 	.dia_digestsize	= 8,
 	.dia_init	= michael_init,
crypto/proc.c +12 -13
diff -u -N -r linux-2.6.9-rc1/crypto/proc.c linux-2.6.9-rc1-sys2/crypto/proc.c
@@ -18,40 +18,39 @@
 #include <linux/seq_file.h>
 #include "internal.h"
 
-extern struct list_head crypto_alg_list;
-extern struct rw_semaphore crypto_alg_sem;
+extern struct subsystem cryptoapi_subsys;
 
 static void *c_start(struct seq_file *m, loff_t *pos)
 {
 	struct list_head *v;
 	loff_t n = *pos;
 
-	down_read(&crypto_alg_sem);
-	list_for_each(v, &crypto_alg_list)
+	down_read(&cryptoapi_subsys.rwsem);
+	list_for_each(v, &cryptoapi_subsys.kset.list)
 		if (!n--)
-			return list_entry(v, struct crypto_alg, cra_list);
+			return list_entry(v, struct kobject, entry);
 	return NULL;
 }
 
 static void *c_next(struct seq_file *m, void *p, loff_t *pos)
 {
-	struct list_head *v = p;
-	
+	struct list_head *e = &(((struct kobject*)p)->entry);
+
 	(*pos)++;
-	v = v->next;
-	return (v == &crypto_alg_list) ?
-		NULL : list_entry(v, struct crypto_alg, cra_list);
+	e = e->next;
+	return (e == &cryptoapi_subsys.kset.list) ?
+		NULL : list_entry(e, struct kobject, entry);
 }
 
 static void c_stop(struct seq_file *m, void *p)
 {
-	up_read(&crypto_alg_sem);
+	up_read(&cryptoapi_subsys.rwsem);
 }
 
 static int c_show(struct seq_file *m, void *p)
 {
-	struct crypto_alg *alg = (struct crypto_alg *)p;
-	
+	struct crypto_alg *alg = container_of(p, struct crypto_alg, cra_obj);
+
 	seq_printf(m, "name         : %s\n", alg->cra_name);
 	seq_printf(m, "module       : %s\n", module_name(alg->cra_module));
crypto/serpent.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/serpent.c linux-2.6.9-rc1-sys2/crypto/serpent.c
@@ -479,7 +479,6 @@
 	.cra_blocksize		=	SERPENT_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct serpent_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(serpent_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	SERPENT_MIN_KEY_SIZE,
 	.cia_max_keysize	=	SERPENT_MAX_KEY_SIZE,
crypto/sha1.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/sha1.c linux-2.6.9-rc1-sys2/crypto/sha1.c
@@ -183,7 +183,6 @@
 	.cra_blocksize	=	SHA1_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct sha1_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	SHA1_DIGEST_SIZE,
 	.dia_init   	= 	sha1_init,
crypto/sha256.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/sha256.c linux-2.6.9-rc1-sys2/crypto/sha256.c
@@ -337,7 +337,6 @@
 	.cra_blocksize	=	SHA256_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct sha256_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	SHA256_DIGEST_SIZE,
 	.dia_init   	= 	sha256_init,
crypto/sha512.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/sha512.c linux-2.6.9-rc1-sys2/crypto/sha512.c
@@ -324,7 +324,6 @@
         .cra_blocksize  = SHA512_HMAC_BLOCK_SIZE,
         .cra_ctxsize    = sizeof(struct sha512_ctx),
         .cra_module     = THIS_MODULE,
-        .cra_list       = LIST_HEAD_INIT(sha512.cra_list),
         .cra_u          = { .digest = {
                                 .dia_digestsize = SHA512_DIGEST_SIZE,
                                 .dia_init       = sha512_init,

@@ -339,7 +338,6 @@
         .cra_blocksize  = SHA384_HMAC_BLOCK_SIZE,
         .cra_ctxsize    = sizeof(struct sha512_ctx),
         .cra_module     = THIS_MODULE,
-        .cra_list       = LIST_HEAD_INIT(sha384.cra_list),
         .cra_u          = { .digest = {
                                 .dia_digestsize = SHA384_DIGEST_SIZE,
                                 .dia_init       = sha384_init,
crypto/sysfs.c +95 -0

95 lines not on this page · raw message

crypto/tea.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/tea.c linux-2.6.9-rc1-sys2/crypto/tea.c
@@ -191,7 +191,6 @@
 	.cra_blocksize		=	TEA_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct tea_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(tea_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	TEA_KEY_SIZE,
 	.cia_max_keysize	=	TEA_KEY_SIZE,

@@ -206,7 +205,6 @@
 	.cra_blocksize		=	XTEA_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct xtea_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(xtea_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	XTEA_KEY_SIZE,
 	.cia_max_keysize	=	XTEA_KEY_SIZE,
crypto/twofish.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/twofish.c linux-2.6.9-rc1-sys2/crypto/twofish.c
@@ -876,7 +876,6 @@
 	.cra_blocksize      =   TF_BLOCK_SIZE,
 	.cra_ctxsize        =   sizeof(struct twofish_ctx),
 	.cra_module         =   THIS_MODULE,
-	.cra_list           =   LIST_HEAD_INIT(alg.cra_list),
 	.cra_u              =   { .cipher = {
 	.cia_min_keysize    =   TF_MIN_KEY_SIZE,
 	.cia_max_keysize    =   TF_MAX_KEY_SIZE,
include/linux/crypto.h +1 -1
diff -u -N -r linux-2.6.9-rc1/include/linux/crypto.h linux-2.6.9-rc1-sys2/include/linux/crypto.h
@@ -94,7 +94,7 @@
 #define cra_compress	cra_u.compress
 
 struct crypto_alg {
-	struct list_head cra_list;
+	struct kobject cra_obj;
 	u32 cra_flags;
 	unsigned int cra_blocksize;
 	unsigned int cra_ctxsize;
#3 lore raw
Quoted 17 lines · Andreas Happe

Hi,

following-up to: James Morris <[email protected]> [040901 09:35]:

Quoted 5 lines

This looks potentially useful, although I'm not sure yet whether the userland crypto API should be exposed via sysfs or a separate filesystem.

I suggest you post the patch to linux-kernel and the crypto API list at:
http://lists.logix.cz/pipermail/cryptoapi as an RFC, for wider feedback.

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie which includes all information which is currently offered by /proc/crypto. This was done by embedding a kobject in struct crypto_alg (include/linux/crypto.h) and using a kset/subsystem instead of the currently used list (crypto_alg->cra_list was removed, as it shouldn't be needed anymore). crypto/proc.c was converted to use the subsystem internal rwlock/list for its iteration of ciphers.

Quoted 3 lines

I think that the place for the cryptoapi-tree in sysfs is wrong (but the others (block, module, bus, class, etc.) seemed worse). But the effort to change this should be neglectable (and centered at syfs.c).

Why not use a class instead of a raw kobject? Wouldn't a struct class_device make things easier for you? That would also put the stuff into /sys/class/cryptoapi which I think makes a bit more sense than /sys/cryptoapi.

Or how about just /sys/class/crypto ?

Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)

thanks,

greg k-h

#4 lore raw
Quoted 2 lines · Greg KH

Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)

The only issue is what to do about potentially expanding this into an API (e.g. open() an algorithm and write to it). Does this sort of thing belong in sysfs?

- James

Signature · 2 lines
James Morris
<[email protected]>
#5 lore raw
Quoted 8 lines · James Morris
Quoted 2 lines · Greg KH

Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)

The only issue is what to do about potentially expanding this into an API (e.g. open() an algorithm and write to it). Does this sort of thing belong in sysfs?

I already proposed to have a 'cryptoapifs' mounted e.g. under /dev/cryptoapi with the "active" entrypoints while /sys would only hold the "status" of the cryptoapi. Would this be a better approach?

Michal Ludvig

Signature · 2 lines
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
#6 lore raw
Quoted 7 lines · Michal Ludvig
Quoted 5 lines · James Morris
Quoted 2 lines · Greg KH

Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)

Quoted 7 lines
Quoted 3 lines

The only issue is what to do about potentially expanding this into an API (e.g. open() an algorithm and write to it). Does this sort of thing belong in sysfs?

I already proposed to have a 'cryptoapifs' mounted e.g. under /dev/cryptoapi with the "active" entrypoints while /sys would only hold the "status" of the cryptoapi. Would this be a better approach?

That sounds acceptable.

thanks,

greg k-h

#7 lore raw
In reply to James Morris
Quoted 8 lines · James Morris
Quoted 2 lines · Greg KH

Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)

The only issue is what to do about potentially expanding this into an API (e.g. open() an algorithm and write to it). Does this sort of thing belong in sysfs?

No, not really. That should be in a special fs just for crypto stuff (cryptofs?) sysfs is for displaying and setting single units of kernel information at at time. So for just showing this crypto information, it would be fine to use.

thanks,

greg k-h

#8 lore raw
In reply to Andreas Happe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas,

I really like the patch - I wanted to do quite the same so thanks that you saved me some work ;-)

Quoted 1 line · Andreas Happe

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie

I'd prefer to have the algorithms grouped by "type" ("cipher", "digest", "compress")? Then the apps could easily see only the algos that thay are interested in...

Quoted 3 lines

Also the different cipher types (digest, compress..) could be seperated into own ksets/directories, but this would make the crypto/proc.c code worse.

There could eventually be a separate crypto/sysfs.c, couldn't?

Quoted 3 lines
| bash-2.05b# cd aes/
| bash-2.05b# ls
| blocksize  maxkeysize  minkeysize  module  name  type

Few notes:
- - some algorithms allow only discrete set of keysizes (e.g. AES can do 128b, 192b and 256b). Can we instead of min/max have a file 'keysize' with either:
minsize-maxsize
or

	size1,size2,size3

?

- - ditto for blocksize?

- - With the future support for hardware crypto accelerators it might be possible to have more modules loaded providing the same algorithm. They may have different priorities and one would be treated as "default". Then I expect the syntax of 'module' file to change from a simple module name to something like:

	# modname:prio:type:whatever
	aes:0:generic:
	aes_i586:1:optimized:
	padlock:2:hardware:default

But for now there is probably nothing to do about it.

Michal Ludvig
- --
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFBPLFADDolCcRbIhgRAksyAJ4t+6m6demqQYdlJm3TnKMkLCSa5QCgrset VlNlUPb0517aLARgI6mt8gk=
=rjsX
-----END PGP SIGNATURE-----

#9 lore raw
Quoted 2 lines · Michal Ludvig

I really like the patch - I wanted to do quite the same so thanks that you saved me some work ;-)

thanks ;).

Quoted 2 lines · Andreas Happe
Quoted 1 line

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie

BTW: the latest incarnation of the patch uses /sys/class/crypto/<cipher-name>.

Quoted 3 lines

I'd prefer to have the algorithms grouped by "type" ("cipher", "digest", "compress")? Then the apps could easily see only the algos that thay are interested in...

jup, but the seqfile code in proc.c would get a lot more uglier. If we could drop proc.c this wouldn�t be a problem.

Quoted 1 line

There could eventually be a separate crypto/sysfs.c, couldn't?

check the patch ;). There's already a sysfs.c with the sysfs-centric stuff.

Quoted 10 lines

Few notes:
- - some algorithms allow only discrete set of keysizes (e.g. AES can do 128b, 192b and 256b). Can we instead of min/max have a file 'keysize' with either:
minsize-maxsize
or

	size1,size2,size3

?

- - ditto for blocksize?

how would you implement this in the crypto_alg struture? The sysfs/procfs integration isn't that problem.

Quoted 9 lines

- - With the future support for hardware crypto accelerators it might be possible to have more modules loaded providing the same algorithm. They may have different priorities and one would be treated as "default". Then I expect the syntax of 'module' file to change from a simple module name to something like:

	# modname:prio:type:whatever
	aes:0:generic:
	aes_i586:1:optimized:
	padlock:2:hardware:default

Isn't this against the "one value per file" - sysfs rule.

Quoted 1 line

Michal Ludvig

--Andreas

#10 lore raw
Quoted 5 lines · Andreas Happe
Quoted 2 lines · Michal Ludvig
Quoted 1 line · Andreas Happe

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie

BTW: the latest incarnation of the patch uses /sys/class/crypto/<cipher-name>.

Where can I get the updated version?

Quoted 6 lines
Quoted 3 lines

I'd prefer to have the algorithms grouped by "type" ("cipher", "digest", "compress")? Then the apps could easily see only the algos that thay are interested in...

jup, but the seqfile code in proc.c would get a lot more uglier. If we could drop proc.c this wouldn´t be a problem.

Hopefully we can ;-) Or does anyone use it? There are not that much userspace programs in any way interacting with the kernel cryptoapi...

Quoted 9 lines
Quoted 9 lines

Few notes:
- - some algorithms allow only discrete set of keysizes (e.g. AES can do 128b, 192b and 256b). Can we instead of min/max have a file 'keysize' with either:
minsize-maxsize
or

	size1,size2,size3

?

Quoted 4 lines
Quoted 1 line

- - ditto for blocksize?

how would you implement this in the crypto_alg struture? The sysfs/procfs integration isn't that problem.

This is a compile time thing, e.g. something like:

	.cia_min_keysize = 1,
	.cia_max_keysize = 128
for variable keysizes, and
	.cia_keysizes = { 128, 192, 256, -1 }

for discrete keysizes.
typeof(cia_keysizes) would be "int[]".

Quoted 11 lines
Quoted 9 lines

- - With the future support for hardware crypto accelerators it might be possible to have more modules loaded providing the same algorithm. They may have different priorities and one would be treated as "default". Then I expect the syntax of 'module' file to change from a simple module name to something like:

	# modname:prio:type:whatever
	aes:0:generic:
	aes_i586:1:optimized:
	padlock:2:hardware:default

Isn't this against the "one value per file" - sysfs rule.

I didn't know about such a rule. If it is that strict we could have a subdir modules with a node for each module (aes, aes_i586, padlock, ...) and a symlink (are symlinks allowed in sysfs?) default pointing to the one with highest preference.

Attached is my patch introducing preferences for current cryptoapi. How can this be done with the kobject model?

- During registration the kobject for a given algo should be looked up. If found (i.e. there already is a module loaded) the new module would be somehow "attached" to it. If not found a new kobject for the algo would be created and then the first module attached to it.

- During lookup the kobject for a requested algo will be further examined and the "struct crypto_alg" of the most preferenced module will be returned.

Could this be done? (I don't know too much about sysfs and kobjects).

Michal Ludvig

Signature · 2 lines
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
crypto/api.c +8 -15
Index: linux-2.6.7/crypto/api.c
===================================================================
@@ -43,14 +43,16 @@
 	down_read(&crypto_alg_sem);
 	
 	list_for_each_entry(q, &crypto_alg_list, cra_list) {
-		if (!(strcmp(q->cra_name, name))) {
-			if (crypto_alg_get(q))
-				alg = q;
-			break;
-		}
+		if (!(strcmp(q->cra_name, name))
+		    && (!alg || alg->cra_preference < q->cra_preference))
+			alg = q;
 	}
 	
+	if (alg && !crypto_alg_get(alg))
+		alg = NULL;
+
 	up_read(&crypto_alg_sem);
+
 	return alg;
 }
 

@@ -163,20 +165,11 @@
 int crypto_register_alg(struct crypto_alg *alg)
 {
 	int ret = 0;
-	struct crypto_alg *q;
 	
 	down_write(&crypto_alg_sem);
-	
-	list_for_each_entry(q, &crypto_alg_list, cra_list) {
-		if (!(strcmp(q->cra_name, alg->cra_name))) {
-			ret = -EEXIST;
-			goto out;
-		}
-	}
-	
 	list_add_tail(&alg->cra_list, &crypto_alg_list);
-out:	
 	up_write(&crypto_alg_sem);
+
 	return ret;
 }
include/linux/crypto.h +5 -0
Index: linux-2.6.7/include/linux/crypto.h
===================================================================
@@ -56,6 +57,10 @@
 #define CRYPTO_UNSPEC			0
 #define CRYPTO_MAX_ALG_NAME		64
 
+#define CRYPTO_PREF_GENERIC		0
+#define CRYPTO_PREF_OPTIMIZED		10
+#define CRYPTO_PREF_HARDAWRE		20
+
 struct scatterlist;
 
 /*

@@ -99,6 +118,7 @@
 	unsigned int cra_blocksize;
 	unsigned int cra_ctxsize;
 	const char cra_name[CRYPTO_MAX_ALG_NAME];
+	unsigned int cra_preference;
 
 	union {
 		struct cipher_alg cipher;
#11 lore raw
Quoted 7 lines · Michal Ludvig
Quoted 3 lines · Andreas Happe
Quoted 1 line · Michal Ludvig

On Wed, 1 Sep 2004, Andreas Happe wrote:

BTW: the latest incarnation of the patch uses /sys/class/crypto/<cipher-name>.

Where can I get the updated version?

It's on my home computer (and I'm on vacation quite now ;). will do some additional testing on friday and will post the patch around the weekend.

It uses class_device (see include/linux/device.h) instead of kobjects.

Quoted 7 lines

This is a compile time thing, e.g. something like:

	.cia_min_keysize = 1,
	.cia_max_keysize = 128
for variable keysizes, and
	.cia_keysizes = { 128, 192, 256, -1 }

for discrete keysizes.
typeof(cia_keysizes) would be "int[]".

can do, but see james morris other patch.

Quoted 3 lines
Quoted 1 line

Isn't this against the "one value per file" - sysfs rule.

I didn't know about such a rule.

yup, is rather strict.

Quoted 2 lines

Attached is my patch introducing preferences for current cryptoapi. How can this be done with the kobject model?

will look into it after I'm home from vacation.

--AndreaS

author
#12 lore raw

Andreas Happe <[email protected]> [040910 12:44]:

Quoted 11 lines · Michal Ludvig
Quoted 8 lines

This is a compile time thing, e.g. something like:

	.cia_min_keysize = 1,
	.cia_max_keysize = 128
for variable keysizes, and
	.cia_keysizes = { 128, 192, 256, -1 }

for discrete keysizes.
typeof(cia_keysizes) would be "int[]".

can do, but see james morris other patch.

*argh*

s/patch/post/

--Andreas

author
#13 lore raw
In reply to Michal Ludvig

Michal Ludvig <[email protected]> [040910 12:44]:

Quoted 9 lines · Andreas Happe
Quoted 6 lines · Michal Ludvig
Quoted 2 lines · Andreas Happe
Quoted 1 line

the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie

BTW: the latest incarnation of the patch uses /sys/class/crypto/<cipher-name>.

Where can I get the updated version?

it is attached. The changes to api.c are very small (it just uses the class_device linked list instead of cra_list).

The only 'drawback' compared to the subsystem - based patch is that I've got to traverse the list by hand and not by something like "kset_find_obj".

--Andreas

arch/i386/crypto/aes.c +0 -1
diff -u -N -r linux-2.6.9-rc1/arch/i386/crypto/aes.c linux-2.6.9-rc1-class/arch/i386/crypto/aes.c
@@ -488,7 +488,6 @@
 	.cra_blocksize		=	AES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct aes_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(aes_alg.cra_list),
 	.cra_u			=	{
 		.cipher = {
 			.cia_min_keysize	=	AES_MIN_KEY_SIZE,
crypto/aes.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/aes.c linux-2.6.9-rc1-class/crypto/aes.c
@@ -437,7 +437,6 @@
 	.cra_blocksize		=	AES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct aes_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(aes_alg.cra_list),
 	.cra_u			=	{
 		.cipher = {
 			.cia_min_keysize	=	AES_MIN_KEY_SIZE,
crypto/api.c +54 -10

116 lines not on this page · raw message

crypto/arc4.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/arc4.c linux-2.6.9-rc1-class/crypto/arc4.c
@@ -75,7 +75,6 @@
 	.cra_blocksize		=	ARC4_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct arc4_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(arc4_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	ARC4_MIN_KEY_SIZE,
 	.cia_max_keysize	=	ARC4_MAX_KEY_SIZE,
crypto/blowfish.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/blowfish.c linux-2.6.9-rc1-class/crypto/blowfish.c
@@ -452,7 +452,6 @@
 	.cra_blocksize		=	BF_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct bf_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	BF_MIN_KEY_SIZE,
 	.cia_max_keysize	=	BF_MAX_KEY_SIZE,
crypto/cast5.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/cast5.c linux-2.6.9-rc1-class/crypto/cast5.c
@@ -821,7 +821,6 @@
 	.cra_blocksize 	= CAST5_BLOCK_SIZE,
 	.cra_ctxsize 	= sizeof(struct cast5_ctx),
 	.cra_module 	= THIS_MODULE,
-	.cra_list 	= LIST_HEAD_INIT(alg.cra_list),
 	.cra_u 		= {
 		.cipher = {
 			.cia_min_keysize = CAST5_MIN_KEY_SIZE,
crypto/cast6.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/cast6.c linux-2.6.9-rc1-class/crypto/cast6.c
@@ -534,7 +534,6 @@
 	.cra_blocksize = CAST6_BLOCK_SIZE,
 	.cra_ctxsize = sizeof(struct cast6_ctx),
 	.cra_module = THIS_MODULE,
-	.cra_list = LIST_HEAD_INIT(alg.cra_list),
 	.cra_u = {
 		  .cipher = {
 			     .cia_min_keysize = CAST6_MIN_KEY_SIZE,
crypto/crc32c.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/crc32c.c linux-2.6.9-rc1-class/crypto/crc32c.c
@@ -80,7 +80,6 @@
 	.cra_blocksize	=	CHKSUM_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct chksum_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list	=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{
 		.digest = {
 			 .dia_digestsize=	CHKSUM_DIGEST_SIZE,
crypto/crypto_null.c +0 -3
diff -u -N -r linux-2.6.9-rc1/crypto/crypto_null.c linux-2.6.9-rc1-class/crypto/crypto_null.c
@@ -59,7 +59,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=       LIST_HEAD_INIT(compress_null.cra_list),
 	.cra_u			=	{ .compress = {
 	.coa_compress 		=	null_compress,
 	.coa_decompress		=	null_decompress } }

@@ -71,7 +70,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=       LIST_HEAD_INIT(digest_null.cra_list),	
 	.cra_u			=	{ .digest = {
 	.dia_digestsize		=	NULL_DIGEST_SIZE,
 	.dia_init   		=	null_init,

@@ -85,7 +83,6 @@
 	.cra_blocksize		=	NULL_BLOCK_SIZE,
 	.cra_ctxsize		=	0,
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(cipher_null.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	NULL_KEY_SIZE,
 	.cia_max_keysize	=	NULL_KEY_SIZE,
crypto/deflate.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/deflate.c linux-2.6.9-rc1-class/crypto/deflate.c
@@ -196,7 +196,6 @@
 	.cra_flags		= CRYPTO_ALG_TYPE_COMPRESS,
 	.cra_ctxsize		= sizeof(struct deflate_ctx),
 	.cra_module		= THIS_MODULE,
-	.cra_list		= LIST_HEAD_INIT(alg.cra_list),
 	.cra_u			= { .compress = {
 	.coa_init		= deflate_init,
 	.coa_exit		= deflate_exit,
crypto/des.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/des.c linux-2.6.9-rc1-class/crypto/des.c
@@ -1245,7 +1245,6 @@
 	.cra_blocksize		=	DES_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct des_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(des_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	DES_KEY_SIZE,
 	.cia_max_keysize	=	DES_KEY_SIZE,

@@ -1260,7 +1259,6 @@
 	.cra_blocksize		=	DES3_EDE_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct des3_ede_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(des3_ede_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	DES3_EDE_KEY_SIZE,
 	.cia_max_keysize	=	DES3_EDE_KEY_SIZE,
crypto/khazad.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/khazad.c linux-2.6.9-rc1-class/crypto/khazad.c
@@ -885,7 +885,6 @@
 	.cra_blocksize		=	KHAZAD_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct khazad_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(khazad_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	KHAZAD_KEY_SIZE,
 	.cia_max_keysize	=	KHAZAD_KEY_SIZE,
crypto/Makefile +2 -1
diff -u -N -r linux-2.6.9-rc1/crypto/Makefile linux-2.6.9-rc1-class/crypto/Makefile
@@ -3,9 +3,10 @@
 #
 
 proc-crypto-$(CONFIG_PROC_FS) = proc.o
+sysfs-crypto-$(CONFIG_SYSFS) = sysfs.o
 
 obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
-			$(proc-crypto-y)
+			$(proc-crypto-y) $(sysfs-crypto-y)
 
 obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
 obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
crypto/md4.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/md4.c linux-2.6.9-rc1-class/crypto/md4.c
@@ -224,7 +224,6 @@
 	.cra_blocksize	=	MD4_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct md4_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),	
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	MD4_DIGEST_SIZE,
 	.dia_init   	= 	md4_init,
crypto/md5.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/md5.c linux-2.6.9-rc1-class/crypto/md5.c
@@ -219,7 +219,6 @@
 	.cra_blocksize	=	MD5_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct md5_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list	=	LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	MD5_DIGEST_SIZE,
 	.dia_init   	= 	md5_init,
crypto/michael_mic.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/michael_mic.c linux-2.6.9-rc1-class/crypto/michael_mic.c
@@ -163,7 +163,6 @@
 	.cra_blocksize	= 8,
 	.cra_ctxsize	= sizeof(struct michael_mic_ctx),
 	.cra_module	= THIS_MODULE,
-	.cra_list	= LIST_HEAD_INIT(michael_mic_alg.cra_list),
 	.cra_u		= { .digest = {
 	.dia_digestsize	= 8,
 	.dia_init	= michael_init,
crypto/proc.c +11 -10
diff -u -N -r linux-2.6.9-rc1/crypto/proc.c linux-2.6.9-rc1-class/crypto/proc.c
@@ -16,9 +16,10 @@
 #include <linux/rwsem.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
+#include <linux/device.h>
 #include "internal.h"
 
-extern struct list_head crypto_alg_list;
+extern struct class cryptoapi_class;
 extern struct rw_semaphore crypto_alg_sem;
 
 static void *c_start(struct seq_file *m, loff_t *pos)

@@ -27,20 +28,20 @@
 	loff_t n = *pos;
 
 	down_read(&crypto_alg_sem);
-	list_for_each(v, &crypto_alg_list)
+	list_for_each(v, &cryptoapi_class.children)
 		if (!n--)
-			return list_entry(v, struct crypto_alg, cra_list);
+			return list_entry(v, struct class_device, node);
 	return NULL;
 }
 
 static void *c_next(struct seq_file *m, void *p, loff_t *pos)
 {
-	struct list_head *v = p;
-	
+	struct list_head *e = &(((struct class_device*)p)->node);
+
 	(*pos)++;
-	v = v->next;
-	return (v == &crypto_alg_list) ?
-		NULL : list_entry(v, struct crypto_alg, cra_list);
+	e = e->next;
+	return (e == &(cryptoapi_class.children)) ?
+		NULL : list_entry(e, struct class_device, node);
 }
 
 static void c_stop(struct seq_file *m, void *p)

@@ -50,8 +51,8 @@
 
 static int c_show(struct seq_file *m, void *p)
 {
-	struct crypto_alg *alg = (struct crypto_alg *)p;
-	
+	struct crypto_alg *alg = (struct crypt_alg*)class_get_devdata((struct class_device*)p);
+
 	seq_printf(m, "name         : %s\n", alg->cra_name);
 	seq_printf(m, "module       : %s\n", module_name(alg->cra_module));
crypto/serpent.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/serpent.c linux-2.6.9-rc1-class/crypto/serpent.c
@@ -479,7 +479,6 @@
 	.cra_blocksize		=	SERPENT_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof(struct serpent_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(serpent_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	SERPENT_MIN_KEY_SIZE,
 	.cia_max_keysize	=	SERPENT_MAX_KEY_SIZE,
crypto/sha1.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/sha1.c linux-2.6.9-rc1-class/crypto/sha1.c
@@ -183,7 +183,6 @@
 	.cra_blocksize	=	SHA1_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct sha1_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	SHA1_DIGEST_SIZE,
 	.dia_init   	= 	sha1_init,
crypto/sha256.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/sha256.c linux-2.6.9-rc1-class/crypto/sha256.c
@@ -337,7 +337,6 @@
 	.cra_blocksize	=	SHA256_HMAC_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct sha256_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	SHA256_DIGEST_SIZE,
 	.dia_init   	= 	sha256_init,
crypto/sha512.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/sha512.c linux-2.6.9-rc1-class/crypto/sha512.c
@@ -324,7 +324,6 @@
         .cra_blocksize  = SHA512_HMAC_BLOCK_SIZE,
         .cra_ctxsize    = sizeof(struct sha512_ctx),
         .cra_module     = THIS_MODULE,
-        .cra_list       = LIST_HEAD_INIT(sha512.cra_list),
         .cra_u          = { .digest = {
                                 .dia_digestsize = SHA512_DIGEST_SIZE,
                                 .dia_init       = sha512_init,

@@ -339,7 +338,6 @@
         .cra_blocksize  = SHA384_HMAC_BLOCK_SIZE,
         .cra_ctxsize    = sizeof(struct sha512_ctx),
         .cra_module     = THIS_MODULE,
-        .cra_list       = LIST_HEAD_INIT(sha384.cra_list),
         .cra_u          = { .digest = {
                                 .dia_digestsize = SHA384_DIGEST_SIZE,
                                 .dia_init       = sha384_init,
crypto/sysfs.c +75 -0

75 lines not on this page · raw message

crypto/tea.c +0 -2
diff -u -N -r linux-2.6.9-rc1/crypto/tea.c linux-2.6.9-rc1-class/crypto/tea.c
@@ -191,7 +191,6 @@
 	.cra_blocksize		=	TEA_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct tea_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(tea_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	TEA_KEY_SIZE,
 	.cia_max_keysize	=	TEA_KEY_SIZE,

@@ -206,7 +205,6 @@
 	.cra_blocksize		=	XTEA_BLOCK_SIZE,
 	.cra_ctxsize		=	sizeof (struct xtea_ctx),
 	.cra_module		=	THIS_MODULE,
-	.cra_list		=	LIST_HEAD_INIT(xtea_alg.cra_list),
 	.cra_u			=	{ .cipher = {
 	.cia_min_keysize	=	XTEA_KEY_SIZE,
 	.cia_max_keysize	=	XTEA_KEY_SIZE,
crypto/twofish.c +0 -1
diff -u -N -r linux-2.6.9-rc1/crypto/twofish.c linux-2.6.9-rc1-class/crypto/twofish.c
@@ -876,7 +876,6 @@
 	.cra_blocksize      =   TF_BLOCK_SIZE,
 	.cra_ctxsize        =   sizeof(struct twofish_ctx),
 	.cra_module         =   THIS_MODULE,
-	.cra_list           =   LIST_HEAD_INIT(alg.cra_list),
 	.cra_u              =   { .cipher = {
 	.cia_min_keysize    =   TF_MIN_KEY_SIZE,
 	.cia_max_keysize    =   TF_MAX_KEY_SIZE,
include/linux/crypto.h +0 -1
diff -u -N -r linux-2.6.9-rc1/include/linux/crypto.h linux-2.6.9-rc1-class/include/linux/crypto.h
@@ -94,7 +94,6 @@
 #define cra_compress	cra_u.compress
 
 struct crypto_alg {
-	struct list_head cra_list;
 	u32 cra_flags;
 	unsigned int cra_blocksize;
 	unsigned int cra_ctxsize;
author
#14 lore raw

Andreas Happe <[email protected]> [040910 12:55]:

Quoted 1 line

[class - based sysfs patch]

hi,
just wanted to know if there's any feedback regarding this patch. It still applies to -rc2 without problems.

--Andreas

#15 lore raw
Quoted 6 lines · Andreas Happe

Andreas Happe <[email protected]> [040910 12:55]:

Quoted 1 line

[class - based sysfs patch]

hi,
just wanted to know if there's any feedback regarding this patch. It still applies to -rc2 without problems.

I have it compiled in my kernel and ... yes, it works ;-)

One thing that I noticed is that it doesn't complain when loading a second module for the same cipher. Say that you have both aes.ko and aes-i586.ko. You load one of them and it is registered for AES algorithm. Then you modprobe the other one and it doesn't make an error, but the module is not loaded. I'm not 100% sure that it is a fault in your patch, though. I haven't tested it with a clean vanilla+your-patch kernel to avoid other possible culprits.

BTW In http://lists.logix.cz/pipermail/cryptoapi/2004/000088.html I described a concept of "preferences" that was done for the current cryptoapi. How to do something similar with your patch applied?

If I'd finally have two or more modules for the same algorithm loaded, how should the /sys subtree look like?

Michal Ludvig

Signature · 2 lines
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
author
#16 lore raw

Michal Ludvig <[email protected]> [040927 11:32]:

Quoted 3 lines

BTW In http://lists.logix.cz/pipermail/cryptoapi/2004/000088.html I described a concept of "preferences" that was done for the current cryptoapi. How to do something similar with your patch applied?

The class - objects are used just for display use.. your patch should apply (sans offsets) without problems.. I don't think that the two different algorithms would be displayed in sysfs as i use the cra_name as directory name (which should be aes for aes and aes-i586).

Quoted 2 lines

If I'd finally have two or more modules for the same algorithm loaded, how should the /sys subtree look like?

good one.

If there are lots of different implementation for a given algorithm it could be worthwhile to create a algorithm and a implementation - directory e.g.

ls /sysfs/class/crypto/implementations would list:
aes-i586 aes-c4 md5 sha1 sha256-c4

and: ls /sysfs/class/crypto/algorithms
aes

with ls /sysfs/class/crypto/algorithms/aes
name type implementations

where implementations is a directory with links to the given implementations in /sysfs/class/crypto/implementations.

Seems like a lot of work if there are only few implementations (like aes and aes-i586).

the same could be done without the implementations - directory. If a new algorithm tries to register itself with a already registered name (and the module name isn't known) it is added to the /sysfs/class/crypto/<cra-name>/implementations - directory as <module-name>. All Algorithm - specific data would be displayed in the <cra-name> directory, the rest in the implementations/<module-name> - directory.

I'm moving to vienna the day after tomorrow so don't expect too fast response times from me.

--Andreas

author
#17 lore raw

just took a glance at preferences for algorithms yesterday. came up with the attached code (does compile, don't think that it will boot, just attached to illustrade my thinkings).

I inserted a cra_family list into cra_alg which stores all algorithms which share the same name but different module names. When selecting an algorithm the preference is looked after (it should be made a writeable sysfs attribute - would make runtime user selection of prefered algorithm very intuitive).

Main problems are removal of algorithms (havn't covered that yet) and the display of different algorithms with same names in sysfs as cra_name is the name of the directory (not module_name(alg->cra_module)).

Creating a hierarchie cra_alg <>- cra_implementation would be the most clean solution. Just add a kset with the different cra_implementations (which would contain a kobject, preference, module pointer) to any given algorithm (which would contain all blocksize, blah data).

--Andreas

author
#18 lore raw

*sigh*

--Andreas

crypto/api.c +27 -6
diff -u -r -N linux-2.6.8/crypto/api.c linux-sysfs/crypto/api.c
@@ -46,7 +46,7 @@
 
 struct crypto_alg *crypto_alg_lookup(const char *name)
 {
-	struct crypto_alg *q, *alg = NULL;
+	struct crypto_alg *q, *tmp=NULL, *alg = NULL;
 	struct class_device *dev;
 
 	if (!name)

@@ -56,9 +56,15 @@
 	
 	list_for_each_entry(dev, &(cryptoapi_class.children), node) {
 		if (!(strcmp(dev->class_id, name))) {
-			q = (struct crypto_alg *)class_get_devdata(dev);
-			if (crypto_alg_get(q))
-				alg = q;
+			alg = q = class_get_devdata(dev);
+
+			list_for_each_entry(tmp, &(q->cra_family), cra_family) {
+				if(tmp->cra_preference > alg->cra_preference)
+					alg = tmp;
+			}
+
+			if(!crypto_alg_get(alg))
+				alg = NULL;
 			break;
 		}
 	}

@@ -177,13 +183,23 @@
 {
 	int ret = 0;
 	struct class_device *dev;
+	struct crypto_alg *tmp;
+	struct list_head *insert_position=NULL;
 	
 	down_write(&crypto_alg_sem);
 	
+	INIT_LIST_HEAD(&(alg->cra_family));
+
 	list_for_each_entry(dev, &(cryptoapi_class.children), node) {
 		if (!(strcmp(dev->class_id, alg->cra_name))) {
-			ret = -EEXIST;
-			goto out;
+			tmp=class_get_devdata(dev);
+
+			insert_position = &(tmp->cra_family);
+			if(!(strcmp(module_name(tmp->cra_module),\
+				    module_name(alg->cra_module)))) {
+				ret = -EEXIST;
+				goto out;
+			}
 		}
 	}
 	

@@ -196,7 +212,12 @@
 	memset(dev, 0, sizeof(*dev));
 	dev->class = &cryptoapi_class;
 	dev->dev   = NULL;
+
+	/* TODO: what to do if alg->cra_name is already in use? */
 	strncpy(dev->class_id, alg->cra_name, BUS_ID_SIZE);
+
+	if(insert_position)
+		list_add(&(alg->cra_family), insert_position);
 	class_device_register(dev);
 
 #ifdef CONFIG_SYSFS
crypto/Kconfig +9 -0
diff -u -r -N linux-2.6.8/crypto/Kconfig linux-sysfs/crypto/Kconfig
@@ -16,6 +16,15 @@
 	  HMAC: Keyed-Hashing for Message Authentication (RFC2104).
 	  This is required for IPSec.
 
+config CRYPTO_PROC
+	bool "Legacy /proc/crypto interface (OBSOLETE)"
+	depends on PROC_FS && CRYPTO
+	help
+	  Displays cipher specific information via /proc/crypto.
+	  Please use /sysfs/class/crypto instead.
+
+	  When in double say Y.
+
 config CRYPTO_NULL
 	tristate "Null algorithms"
 	depends on CRYPTO
crypto/Makefile +1 -1
diff -u -r -N linux-2.6.8/crypto/Makefile linux-sysfs/crypto/Makefile
@@ -2,7 +2,7 @@
 # Cryptographic API
 #
 
-proc-crypto-$(CONFIG_PROC_FS) = proc.o
+proc-crypto-$(CONFIG_CRYPTO_PROC) = proc.o
 sysfs-crypto-$(CONFIG_SYSFS) = sysfs.o
 
 obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
crypto/sysfs.c +4 -0
diff -u -r -N linux-2.6.8/crypto/sysfs.c linux-sysfs/crypto/sysfs.c
@@ -14,6 +14,7 @@
 	.release = cryptoapi_release,
 };
 
+/* TODO: add cryptoapi_set_preference  */
 static ssize_t cryptoapi_show_name(struct class_device *dev, char *buffer);
 static ssize_t cryptoapi_show_blocksize(struct class_device *dev, char *buffer);
 static ssize_t cryptoapi_show_digestsize(struct class_device *dev, char *buffer);

@@ -21,6 +22,7 @@
 static ssize_t cryptoapi_show_module(struct class_device *dev, char *buffer);
 static ssize_t cryptoapi_show_maxkeysize(struct class_device *dev, char *buffer);
 static ssize_t cryptoapi_show_minkeysize(struct class_device *dev, char *buffer);
+static ssize_t cryptoapi_show_preference(struct class_device *dev, char *buffer);
 
 CLASS_DEVICE_ATTR(blocksize, 0444, cryptoapi_show_blocksize, NULL);
 CLASS_DEVICE_ATTR(digestsize, 0444, cryptoapi_show_digestsize, NULL);

@@ -29,6 +31,7 @@
 CLASS_DEVICE_ATTR(name, 0444, cryptoapi_show_name, NULL);
 CLASS_DEVICE_ATTR(module, 0444, cryptoapi_show_module, NULL);
 CLASS_DEVICE_ATTR(type, 0444, cryptoapi_show_type, NULL);
+CLASS_DEVICE_ATTR(preference, 0444, cryptoapi_show_preference, NULL);
 
 void cryptoapi_release(struct class_device *class_dev) {
 	kfree(class_dev);

@@ -46,6 +49,7 @@
 cryptoapi_show(minkeysize, cipher.cia_min_keysize, %u\n);
 cryptoapi_show(maxkeysize, cipher.cia_max_keysize, %u\n);
 cryptoapi_show(name, name, %s\n);
+cryptoapi_show(preference, preference, %u\n);
 
 #undef cryptoapi_show
crypto/whirlpool.c +0 -1
diff -u -r -N linux-2.6.8/crypto/whirlpool.c linux-sysfs/crypto/whirlpool.c
@@ -1106,7 +1106,6 @@
 	.cra_blocksize	=	WHIRLPOOL_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct whirlpool_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),	
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	WHIRLPOOL_DIGEST_SIZE,
 	.dia_init   	= 	whirlpool_init,
include/linux/crypto.h +6 -0
diff -u -r -N linux-2.6.8/include/linux/crypto.h linux-sysfs/include/linux/crypto.h
@@ -56,6 +56,10 @@
 #define CRYPTO_UNSPEC			0
 #define CRYPTO_MAX_ALG_NAME		64
 
+#define CRYPTO_PREF_GENERIC		0
+#define CRYPTO_PREF_OPTIMIZED		10
+#define CRYPTO_PREF_HARDWARE		20
+
 struct scatterlist;
 
 /*

@@ -97,6 +101,7 @@
 	u32 cra_flags;
 	unsigned int cra_blocksize;
 	unsigned int cra_ctxsize;
+	unsigned int cra_preference;
 	const char cra_name[CRYPTO_MAX_ALG_NAME];
 
 	union {

@@ -105,6 +110,7 @@
 		struct compress_alg compress;
 	} cra_u;
 	
+	struct list_head cra_family;
 	struct module *cra_module;
 };
#19 lore raw
In reply to Andreas Happe
Quoted 3 lines · Andreas Happe

just took a glance at preferences for algorithms yesterday. came up with the attached code (does compile, don't think that it will boot, just attached to illustrade my thinkings).

I'll give it a try and read something more about kobjects and ksets as well ;-)

Quoted 5 lines

I inserted a cra_family list into cra_alg which stores all algorithms which share the same name but different module names. When selecting an algorithm the preference is looked after (it should be made a writeable sysfs attribute - would make runtime user selection of prefered algorithm very intuitive).

For now it could be a module option or even hardcoded in the .ko. It won't be user-writable anyway, only root-writable. And if root wouldn't want to use the most preferred module, he could simply not load it...

The reason why I wanted the cra_preference is a situation where a given functionality is non-modular and compiled into the kernel and requires an algorithm thet in turn will have to be compiled in as well. Distributors would of course select the pure software implementation for this. But then you install a cryptocard - without preferences you couldn't load a module with driver for it.

Quoted 8 lines

Main problems are removal of algorithms (havn't covered that yet) and the display of different algorithms with same names in sysfs as cra_name is the name of the directory (not module_name(alg->cra_module)).

Creating a hierarchie cra_alg <>- cra_implementation would be the most clean solution. Just add a kset with the different cra_implementations (which would contain a kobject, preference, module pointer) to any given algorithm (which would contain all blocksize, blah data).

Michal Ludvig

Signature · 2 lines
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
#20 lore raw
In reply to Andreas Happe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Happe told me that:

Quoted 18 lines

Michal Ludvig <[email protected]> [040927 11:32]:

Quoted 3 lines

If I'd finally have two or more modules for the same algorithm loaded, how
should the /sys subtree look like?

good one.

If there are lots of different implementation for a given algorithm it could be worthwhile to create a algorithm and a implementation - directory e.g.

ls /sysfs/class/crypto/implementations would list:
aes-i586 aes-c4 md5 sha1 sha256-c4

and: ls /sysfs/class/crypto/algorithms
aes

Quoted 8 lines

with ls /sysfs/class/crypto/algorithms/aes
name type implementations

where implementations is a directory with links to the given implementations in /sysfs/class/crypto/implementations.

Seems like a lot of work if there are only few implementations (like aes and aes-i586).

Once we have a support for hardware cryptocards it will be usefull. I'm already having the VIA PadLock patch that adds yet another AES implementation. For VIA C7 it will also support SHA (one module, two algorithms? why not ;-)

IMHO it is worth having it done "right and expandable" since the beginning (changing the /sys tree once it goes mainline will be harder).

Michal Ludvig
- --
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBWrUUDDolCcRbIhgRAqU7AKCCKEUplTD8PJldxT0yodC1M52UjQCg2DSx Im6Amy3cGI+UhUqo4s/4IVk=
=fqyy
-----END PGP SIGNATURE-----

#21 lore raw
In reply to Andreas Happe
Quoted 2 lines · Andreas Happe

just wanted to know if there's any feedback regarding this patch. It still applies to -rc2 without problems.

I'd like to replace /proc/crypto with this, but don't know how to do so with the current development model. Do we start issuing warnings (i.e. "this is going to disappear in one year") via printk now when someone accesses /proc/crypto ?

- James

Signature · 2 lines
James Morris
<[email protected]>
author
#22 lore raw

PATCH 1/2 cryptoapi: update sysfs-patch

Just removes the cra_list entry from the whirlpool - cipher.

please apply after the old patch.

Signed-off-by Andreas Happe <[email protected]>
crypto/whirlpool.c +0 -1
diff -u -r -N linux-2.6.8/crypto/whirlpool.c linux-sysfs/crypto/whirlpool.c
@@ -1106,7 +1106,6 @@
 	.cra_blocksize	=	WHIRLPOOL_BLOCK_SIZE,
 	.cra_ctxsize	=	sizeof(struct whirlpool_ctx),
 	.cra_module	=	THIS_MODULE,
-	.cra_list       =       LIST_HEAD_INIT(alg.cra_list),	
 	.cra_u		=	{ .digest = {
 	.dia_digestsize	=	WHIRLPOOL_DIGEST_SIZE,
 	.dia_init   	= 	whirlpool_init,
author
#23 lore raw

Re: [PATCH 2.6.9-rc2 2/2] cryptoapi: make /proc/crypto optional

creates a new Kconfig entry for the /proc/crypto - file and mark it as OBSOLETE. This patch is just compile tested and applies after patch-2.6.9-rc1-cryptoapi-class-2.

Signed-of-by Andreas Happe <[email protected]>
crypto/Kconfig +9 -0
diff -u -r -N linux-2.6.8/crypto/Kconfig linux-sysfs/crypto/Kconfig
@@ -16,6 +16,15 @@
 	  HMAC: Keyed-Hashing for Message Authentication (RFC2104).
 	  This is required for IPSec.
 
+config CRYPTO_PROC
+	bool "Legacy /proc/crypto interface (OBSOLETE)"
+	depends on PROC_FS && CRYPTO
+	help
+	  Displays cipher specific information via /proc/crypto.
+	  Please use /sysfs/class/crypto instead.
+
+	  When in double say Y.
+
 config CRYPTO_NULL
 	tristate "Null algorithms"
 	depends on CRYPTO
crypto/Makefile +1 -1
diff -u -r -N linux-2.6.8/crypto/Makefile linux-sysfs/crypto/Makefile
@@ -2,7 +2,7 @@
 # Cryptographic API
 #
 
-proc-crypto-$(CONFIG_PROC_FS) = proc.o
+proc-crypto-$(CONFIG_CRYPTO_PROC) = proc.o
 sysfs-crypto-$(CONFIG_SYSFS) = sysfs.o
 
 obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
#24 lore raw

Re: [PATCH 2.6.9-rc2 2/2] cryptoapi: make /proc/crypto optional

Hi Andreas,

just one little thing I noticed:

On Tue, Sep 28, 2004 at 02:23:32PM +0200, Andreas Happe told us:

Quoted 5 lines

diff -u -r -N linux-2.6.8/crypto/Kconfig linux-sysfs/crypto/Kconfig

crypto/Kconfig +0 -0
@@ -16,6 +16,15 @@
 	  HMAC: Keyed-Hashing for Message Authentication (RFC2104).

crypto/Kconfig line 26

Quoted 10 lines
crypto/Kconfig +8 -0
 	  This is required for IPSec.
 
+config CRYPTO_PROC
+	bool "Legacy /proc/crypto interface (OBSOLETE)"
+	depends on PROC_FS && CRYPTO
+	help
+	  Displays cipher specific information via /proc/crypto.
+	  Please use /sysfs/class/crypto instead.
+
+	  When in double say Y.

In double?? Probably should be "in doubt"...

Sven

Signature · 2 lines
Linux zion 2.6.9-rc1-mm4 #1 Tue Sep 7 12:57:19 CEST 2004 i686 athlon i386 GNU/Linux
 16:31:14  up 2 days, 15:44,  3 users,  load average: 0.21, 0.07, 0.02
#26 lore raw
In reply to Michal Ludvig
Quoted 3 lines · Michal Ludvig

I'd prefer to have the algorithms grouped by "type" ("cipher", "digest", "compress")? Then the apps could easily see only the algos that thay are interested in...

This could be done with symlinks. Have a master algorithim directory, and symlinks to different views (e.g. 'ciphers').

Quoted 10 lines

Few notes:
- - some algorithms allow only discrete set of keysizes (e.g. AES can do 128b, 192b and 256b). Can we instead of min/max have a file 'keysize' with either:
minsize-maxsize
or

	size1,size2,size3

?

- - ditto for blocksize?

I don't think it's worth complicating the kernel code just to see that AES does in fact have the three key sizes required by the specification.

- James

Signature · 2 lines
James Morris
<[email protected]>