Am Freitag, 24. November 2017, 17:10:59 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> That's more-or-less what I did. Here:
>
> var allAlgs = map[int][]algDesc{
> ALG_AEAD: []algDesc{
> // templates:
> {"authencesn", []int{ALG_HASH, ALG_BLKCIPHER}},
> {"gcm", []int{ALG_CIPHER}},
>
> ALG_AEAD means that all of these names produce ALG_AEAD as the result.
> Names that has arguments after them (authencesn, gcm) are templates,
> and the list of arguments denote number and types of arguments for the
> template.
>
> So here authencesn is a template that produces AEAD and has 2
> arguments: first is ALG_HASH, second is ALG_BLKCIPHER.
> Similarly, gsm is template that produces AEAD and has 1 argument of type
> CIPHER.
>
> ...
> // algorithms:
> {"gcm(aes)", nil},
> {"__gcm-aes-aesni", nil},
>
> If second value is nil, that's a complete algorithm (also of type
> AEAD). I pulled in all registered implementations, so the contain the
> specialized implementations like "gcm(aes)", but note that gsm is also
> described as template above so fuzzer can use other inner ALG_CIPHER
> algorithms with gsm.
Thanks for the clarification -- as said, I am not very fluent in GO yet. :-)
>
> > Start another test where you arbitrarily mix-n-match templates and ciphers
> > or even bogus names, NULL, etc.
> >
> >
> > One word of warning: some cipher names may look like templates, but they
> > are not: gcm(aes) in arch/x86/crypto/ is a complete cipher and not
> > consisting of templates. Thus, I would always use the driver names
> > (gcm-aes-aesni for the given example) to ensure you test exactly the
> > cipher you had in mind.
> I've pulled all registered algs from kernel with the following code:
>
> void crypto_dumb(void)
> {
> struct crypto_alg *alg;
> const char *type;
>
> down_write(&crypto_alg_sem);
> list_for_each_entry(alg, &crypto_alg_list, cra_list) {
> pr_err("name=%s driver=%s async=%d type=%d\n",
> alg->cra_name, alg->cra_driver_name,
> !!(alg->cra_flags & CRYPTO_ALG_ASYNC),
> alg->cra_flags & CRYPTO_ALG_TYPE_MASK);
> }
> up_write(&crypto_alg_sem);
> }
I would not obtain the list from a running kernel. Many ciphers are
implemented in modules that are loaded on demand (or sometimes even manually).
This list therefore is not complete per definition. Thus, I would rather grep
through the code and search for cra_driver_name.
And once you get to templates, it is even more imperative to grep the code:
Only full ciphers are listed in the given list. A template itself is never a
cipher and will not show up there. Only once a template is combined into a
full cipher, it will be registered in the list at runtime.
Note, the traversed list is what forms /proc/crypto.
Thus, after a boot, you will not see, say, rfc4106(gcm(aes)) in /proc/crypto
(or that list). But after one allocation of that cipher, it suddenly pops up
in /proc/crypto or that list.
>
> so I've got these "gcm(aes)" as well. Which is why you see
> {"gcm(aes)", nil} in algorithms section.
>
> However, the name was actually "__gcm-aes-aesni", not "gcm-aes-aesni".
> But kernel does not let me allocate neither of them (EINVAL in both
> cases).
Very good. Please leave such test, because they must not be allocatable.
Ciao
Stephan
