Re: [cryptoapi/sysfs] display cipher details in sysfs

From: Michal Ludvig
Date: Tue Sep 07 2004 - 10:57:38 EST


On Tue, 7 Sep 2004, Andreas Happe wrote:

> On Mon, Sep 06, 2004 at 08:49:30PM +0200, Michal Ludvig wrote:
> > On Wed, 1 Sep 2004, Andreas Happe wrote:
> > > 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?

> > 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...

> > 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.

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[]".

> > - - 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
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michalIndex: linux-2.6.7/crypto/api.c
===================================================================
--- linux-2.6.7.orig/crypto/api.c
+++ 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;
}

Index: linux-2.6.7/include/linux/crypto.h
===================================================================
--- linux-2.6.7.orig/include/linux/crypto.h
+++ 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;