Hi,
following-up to: James Morris <[email protected]> [040901 09:35]:
>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
On Wed, Sep 01, 2004 at 10:28:19AM +0200, Andreas Happe wrote:
> Hi,
>
> following-up to: James Morris <[email protected]> [040901 09:35]:
> >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).
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
-----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 ;-)
On Wed, 1 Sep 2004, Andreas Happe wrote:
> 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...
> 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?
> | 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-----
On Mon, Sep 06, 2004 at 08:49:30PM +0200, Michal Ludvig wrote:
> I really like the patch - I wanted to do quite the same so thanks that you
> saved me some work ;-)
thanks ;).
> 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>.
> 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.
> 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.
> 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.
> - - 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.
> Michal Ludvig
--Andreas
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/michal
On Mon, 6 Sep 2004, Michal Ludvig wrote:
> 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').
> 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
--
James Morris
<[email protected]>
On Sun, 5 Sep 2004, Greg KH wrote:
> 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
--
James Morris
<[email protected]>
On Tue, 7 Sep 2004, James Morris wrote:
> On Sun, 5 Sep 2004, Greg KH wrote:
>
> > 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
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
On Tue, Sep 07, 2004 at 12:37:48PM -0400, James Morris wrote:
> On Sun, 5 Sep 2004, Greg KH wrote:
>
> > 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
On Tue, Sep 07, 2004 at 05:49:14PM +0200, Michal Ludvig wrote:
> 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:
> > 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.
> 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.
> > Isn't this against the "one value per file" - sysfs rule.
>
> I didn't know about such a rule.
yup, is rather strict.
> 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
On Tue, Sep 07, 2004 at 06:47:06PM +0200, Michal Ludvig wrote:
> On Tue, 7 Sep 2004, James Morris wrote:
>
> > On Sun, 5 Sep 2004, Greg KH wrote:
> >
> > > 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?
That sounds acceptable.
thanks,
greg k-h
Andreas Happe <[email protected]> [040910 12:44]:
>On Tue, Sep 07, 2004 at 05:49:14PM +0200, Michal Ludvig wrote:
>
>> 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
Michal Ludvig <[email protected]> [040910 12:44]:
>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?
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
Andreas Happe <[email protected]> [040910 12:55]:
> [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
On Mon, 27 Sep 2004, Andreas Happe wrote:
> Andreas Happe <[email protected]> [040910 12:55]:
> > [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
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
On Mon, 27 Sep 2004, Andreas Happe wrote:
> 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
--
James Morris
<[email protected]>
Just removes the cra_list entry from the whirlpool - cipher.
please apply after the old patch.
Signed-off-by: Andreas Happe <[email protected]>
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]>
Michal Ludvig <[email protected]> [040927 11:32]:
>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).
>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
Hi Andreas,
just one little thing I noticed:
On Tue, Sep 28, 2004 at 02:23:32PM +0200, Andreas Happe told us:
> diff -u -r -N linux-2.6.8/crypto/Kconfig linux-sysfs/crypto/Kconfig
> --- linux-2.6.8/crypto/Kconfig 2004-09-28 12:50:31.000000000 +0200
> +++ linux-sysfs/crypto/Kconfig 2004-09-28 12:18:25.000000000 +0200
> @@ -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.
In double?? Probably should be "in doubt"...
Sven
--
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
Sven Schuster <[email protected]> [040929 09:17]:
>
>Hi Andreas,
>
>just one little thing I noticed:
thanks,
>> + When in double say Y.
>
>In double?? Probably should be "in doubt"...
*blink* ?hm.. updated patch can be found at:
http://snikt.net/kernel/patch-2.6.9-rc2-make_proc_crypto_optional-2
--Andreas
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
*sigh*
--Andreas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Happe told me that:
> Michal Ludvig <[email protected]> [040927 11:32]:
>
>> 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).
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-----
On Wed, 29 Sep 2004, Andreas Happe wrote:
> 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 ;-)
> 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.
> 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
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal