[RFC,HBK:,2/8] hw-bound-key: flag-is_hbk added to the tfm

Commit Message

Pankaj Gupta Sept. 6, 2022, 6:51 a.m. UTC

Consumer of the kernel crypto api, after allocating
the transformation, sets this flag based on the basis
of the type of key consumer has. This helps:

- This helps to influence the core processing logic
  for the encapsulated algorithm.
- This flag is set by the consumer after allocating
  the tfm and before calling the function crypto_xxx_setkey().

Signed-off-by: Pankaj Gupta <[e-mail]>
---
 include/linux/crypto.h | 2 ++
 1 file changed, 2 insertions(+)

Comments

Herbert Xu Sept. 6, 2022, 6:43 a.m. UTC | #1

On Tue, Sep 06, 2022 at 12:21:51PM +0530, Pankaj Gupta wrote:
> Consumer of the kernel crypto api, after allocating
> the transformation, sets this flag based on the basis
> of the type of key consumer has. This helps:
> 
> - This helps to influence the core processing logic
>   for the encapsulated algorithm.
> - This flag is set by the consumer after allocating
>   the tfm and before calling the function crypto_xxx_setkey().
> 
> Signed-off-by: Pankaj Gupta <[e-mail]>
> ---
>  include/linux/crypto.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 2324ab6f1846..b4fa83ca87bd 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -639,6 +639,8 @@ struct crypto_tfm {
>  
>  	u32 crt_flags;
>  
> +	unsigned int is_hbk;
> +

We already have plenty of drivers with hardware keys in the tree.
Plesae explain why the current support is inadequate and you need
to do this.

Thanks,

Pankaj Gupta Sept. 7, 2022, 7:22 a.m. UTC | #2

> -----Original Message-----
> From: Herbert Xu <[e-mail]>
> Sent: Tuesday, September 6, 2022 12:13 PM
> To: Pankaj Gupta <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; Sahil Malhotra
> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
> Subject: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added to
> the tfm
> 
> Caution: EXT Email
> 
> On Tue, Sep 06, 2022 at 12:21:51PM +0530, Pankaj Gupta wrote:
> > Consumer of the kernel crypto api, after allocating the
> > transformation, sets this flag based on the basis of the type of key
> > consumer has. This helps:
> >
> > - This helps to influence the core processing logic
> >   for the encapsulated algorithm.
> > - This flag is set by the consumer after allocating
> >   the tfm and before calling the function crypto_xxx_setkey().
> >
> > Signed-off-by: Pankaj Gupta <[e-mail]>
> > ---
> >  include/linux/crypto.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/crypto.h b/include/linux/crypto.h index
> > 2324ab6f1846..b4fa83ca87bd 100644
> > --- a/include/linux/crypto.h
> > +++ b/include/linux/crypto.h
> > @@ -639,6 +639,8 @@ struct crypto_tfm {
> >
> >       u32 crt_flags;
> >
> > +     unsigned int is_hbk;
> > +
> 
> We already have plenty of drivers with hardware keys in the tree.
> Plesae explain why the current support is inadequate and you need to do
> this.
> 
Current support, does not permit the hardware to support both types of keys: HBK & Plain Key, at the same time.

This change is generic and permit any driver that supports both- HBK and plain-key, to differentiate and use the keys accordingly.

> Thanks,
> --
> Email: Herbert Xu <[e-mail]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2F&amp;data=05%7C01%7Cpankaj.gupta%40nx
> p.com%7Cffd6105be88e4b82546c08da8fd33b6e%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637980434686220485%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&amp;sdata=AErrjpwh%2FRZSCNDDbtH%2FWW
> %2B39J%2FrxPJwak2X2Fk%2BWBg%3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7Cpankaj.g
> upta%40nxp.com%7Cffd6105be88e4b82546c08da8fd33b6e%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C637980434686220485%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=%2F7axxa8nrYDiItrwcZi
> AfRTVc%2F25Ln5IgUzr%2F1uK%2FNk%3D&amp;reserved=0

Herbert Xu Sept. 7, 2022, 7:26 a.m. UTC | #3

On Wed, Sep 07, 2022 at 07:22:42AM +0000, Pankaj Gupta wrote:
>
> Current support, does not permit the hardware to support both types of keys: HBK & Plain Key, at the same time.
> 
> This change is generic and permit any driver that supports both- HBK and plain-key, to differentiate and use the keys accordingly.

Existing drivers simply register hardware keys under a different
algorithm name, there is no reason why they can't coexist with a
plain key.

Cheers,

Pankaj Gupta Sept. 7, 2022, 9:58 a.m. UTC | #4

> -----Original Message-----
> From: Herbert Xu <[e-mail]>
> Sent: Wednesday, September 7, 2022 12:56 PM
> To: Pankaj Gupta <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; Sahil Malhotra
> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk
> added to the tfm
> 
> Caution: EXT Email
> 
> On Wed, Sep 07, 2022 at 07:22:42AM +0000, Pankaj Gupta wrote:
> >
> > Current support, does not permit the hardware to support both types of
> keys: HBK & Plain Key, at the same time.
> >
> > This change is generic and permit any driver that supports both- HBK and
> plain-key, to differentiate and use the keys accordingly.
> 
> Existing drivers simply register hardware keys under a different algorithm
> name, there is no reason why they can't coexist with a plain key.
> 

Thanks for the comments.

Intention is to only secure the key buffer, at run-time.
Not to change the working of the crypto algorithm. Algorithm would be working exactly same for plain and HBK.

There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
Modifying the algorithm name in these IP(s), is not always allowed or easy to maintain.

While, this patch-set allows to use the same algorithm name, 
and hence prevents any changes required to the user(3rd Party IPs) of kernel crypto layer.

Regards,

> Cheers,
> --
> Email: Herbert Xu <[e-mail]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2F&amp;data=05%7C01%7Cpankaj.gupta%40nx
> p.com%7C9bc412605fa243702f3a08da90a2602c%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637981324324251974%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&amp;sdata=b1ImbcEMa9jticFU7yrpwHXuuQEog
> KLrjuiE%2FFpcYyA%3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7Cpankaj.g
> upta%40nxp.com%7C9bc412605fa243702f3a08da90a2602c%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C0%7C637981324324251974%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cP4js5Q0QPBJfvlrYDi0j6R
> IGFpqHtJOSa9C7YC2IXM%3D&amp;reserved=0

Herbert Xu Sept. 7, 2022, 10:10 a.m. UTC | #5

On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
>
> There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> Modifying the algorithm name in these IP(s), is not always allowed or easy to maintain.

So the objective is to support out-of-tree modules?

There is no way I'm merging this then.

Thanks,

Varun Sethi Sept. 12, 2022, 5:19 p.m. UTC | #6

Hi Herbert
Please find response inline.


Regards
Varun

> -----Original Message-----
> From: Herbert Xu <[e-mail]>
> Sent: Wednesday, September 7, 2022 3:40 PM
> To: Pankaj Gupta <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-security-
> [e-mail]; Sahil Malhotra <[e-mail]>; Kshitiz
> Varshney <[e-mail]>; Horia Geanta <[e-mail]>;
> Varun Sethi <[e-mail]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
> 
> Caution: EXT Email
> 
> On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> >
> > There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> > Modifying the algorithm name in these IP(s), is not always allowed or easy to
> maintain.
> 
> So the objective is to support out-of-tree modules?
[Varun] No, the intention is not to use out of tree modules but to allow seamless use of crytpo ciphers with keys backed by security co-processors (keys only visible to security co-processors), by Linux kernel and userspace components. Hardware backed keys are being introduced as a variant of existing Trusted keys, with the difference that these are not un-sealed and released in plain to the kernel memory. With the current patchset, the existing set of ciphers can be used along with newly introduced hardware backed flag. The security co-processor driver is able to interpret the flag and subsequently program the hardware, to interpret the supplied key as a hardware backed key.
> 
> There is no way I'm merging this then.
> 
> Thanks,
> --
> Email: Herbert Xu <[e-mail]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&amp;data=05%7C01%7CV.Sethi%40nxp.com%7Cd
> ec165619848426b9c9008da90b946da%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637981422690327443%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&amp;sdata=kKaGEvKOmUbV8hCh6T9Fswfo39jg%2BqbxYavPcfJS
> h3E%3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7CV.Sethi%40nxp.
> com%7Cdec165619848426b9c9008da90b946da%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637981422690327443%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&amp;sdata=vSNYijBOH5mCmOzZW02R0sNzNNrtTWkD
> vF8%2FpwlTUqk%3D&amp;reserved=0

Herbert Xu Sept. 13, 2022, 2:05 a.m. UTC | #7

On Mon, Sep 12, 2022 at 05:19:44PM +0000, Varun Sethi wrote:
>
> > On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> > >
> > > There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> > > Modifying the algorithm name in these IP(s), is not always allowed or easy to
> > maintain.
> > 
> > So the objective is to support out-of-tree modules?
> [Varun] No, the intention is not to use out of tree modules but to allow seamless use of crytpo ciphers with keys backed by security co-processors (keys only visible to security co-processors), by Linux kernel and userspace components. Hardware backed keys are being introduced as a variant of existing Trusted keys, with the difference that these are not un-sealed and released in plain to the kernel memory. With the current patchset, the existing set of ciphers can be used along with newly introduced hardware backed flag. The security co-processor driver is able to interpret the flag and subsequently program the hardware, to interpret the supplied key as a hardware backed key.

Well I asked why isn't the existing arrangement for hardware key
algorithms sufficient, and I was given the response that you needed
this for compatibility with third-party IP(s).

Now are you saying this is not the case? So the existing framework
should work then?

Cheers,

Varun Sethi Sept. 13, 2022, 10:01 a.m. UTC | #8

Hi Herbert,
Please find response inline.

Regards
Varun

> -----Original Message-----
> From: Herbert Xu <[e-mail]>
> Sent: Tuesday, September 13, 2022 7:36 AM
> To: Varun Sethi <[e-mail]>
> Cc: Pankaj Gupta <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-security-
> [e-mail]; Sahil Malhotra <[e-mail]>; Kshitiz
> Varshney <[e-mail]>; Horia Geanta <[e-mail]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
> 
> Caution: EXT Email
> 
> On Mon, Sep 12, 2022 at 05:19:44PM +0000, Varun Sethi wrote:
> >
> > > On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> > > >
> > > > There are 3rd party IP(s), which uses kernel for crypto-algorithm's
> operations.
> > > > Modifying the algorithm name in these IP(s), is not always allowed
> > > > or easy to
> > > maintain.
> > >
> > > So the objective is to support out-of-tree modules?
> > [Varun] No, the intention is not to use out of tree modules but to allow
> seamless use of crytpo ciphers with keys backed by security co-processors (keys
> only visible to security co-processors), by Linux kernel and userspace
> components. Hardware backed keys are being introduced as a variant of existing
> Trusted keys, with the difference that these are not un-sealed and released in
> plain to the kernel memory. With the current patchset, the existing set of ciphers
> can be used along with newly introduced hardware backed flag. The security co-
> processor driver is able to interpret the flag and subsequently program the
> hardware, to interpret the supplied key as a hardware backed key.
> 
> Well I asked why isn't the existing arrangement for hardware key algorithms
> sufficient, and I was given the response that you needed this for compatibility
> with third-party IP(s).
> 
> Now are you saying this is not the case? So the existing framework should work
> then?
> 
[Varun] The proposed patchset makes things more scalable. With the hardware backed key flag, there's no need for the security co-processor driver to register separate set of algorithms. This makes things simpler and more scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to use standard set of algorithms and leave the key specific complexity to the driver.

> Cheers,
> --
> Email: Herbert Xu <[e-mail]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&amp;data=05%7C01%7CV.Sethi%40nxp.com%7C6
> 51bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=b%2BjXwEqMEomgvSpLVnNzuWRNbmfQF4pX5hitrFh
> Frww%3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7CV.Sethi%40nxp.
> com%7C651bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=6VRL5smACsEevXL8HKs2ADlni9G%2F9J0q7E
> 3Q2emxVzU%3D&amp;reserved=0

Herbert Xu Sept. 13, 2022, 10:28 a.m. UTC | #9

On Tue, Sep 13, 2022 at 10:01:13AM +0000, Varun Sethi wrote:
>
> [Varun] The proposed patchset makes things more scalable. With the hardware backed key flag, there's no need for the security co-processor driver to register separate set of algorithms. This makes things simpler and more scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to use standard set of algorithms and leave the key specific complexity to the driver.

Users already need to specify which driver they are going to use in
order to actually access the hardware keys instead of getting a software
implementation of the same algorithm.

So I don't see what extra burdens are placed on them by the current
regime.

Cheers,

Varun Sethi Sept. 21, 2022, 11:07 a.m. UTC | #10

Hi Herbert,
Please find comments inline.



Regards
Varun

> -----Original Message-----
> From: Herbert Xu <[e-mail]>
> Sent: Tuesday, September 13, 2022 3:59 PM
> To: Varun Sethi <[e-mail]>
> Cc: Pankaj Gupta <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-security-
> [e-mail]; Sahil Malhotra <[e-mail]>; Kshitiz
> Varshney <[e-mail]>; Horia Geanta <[e-mail]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
> 
> Caution: EXT Email
> 
> On Tue, Sep 13, 2022 at 10:01:13AM +0000, Varun Sethi wrote:
> >
> > [Varun] The proposed patchset makes things more scalable. With the
> hardware backed key flag, there's no need for the security co-processor driver
> to register separate set of algorithms. This makes things simpler and more
> scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to
> use standard set of algorithms and leave the key specific complexity to the
> driver.
> 
> Users already need to specify which driver they are going to use in order to
> actually access the hardware keys instead of getting a software implementation
> of the same algorithm.
> 
> So I don't see what extra burdens are placed on them by the current regime.
[Varun] Problem with the current approach is that it's completely disconnected from the kernel keyrings. We are using the trusted key rings for storing the hardware backed keys. Now, for the hardware backed keys we can still continue to use the existing generic algorithms exposed by the crypto drivers. With our approach the driver can distinguish between a hardware backed key and a plain key, thus perform the relevant operation. 

As a part of our patchset we are also proposing modifications to the trusted keys, in order to store additional meta data associated with the key.  

> 
> Cheers,
> --
> Email: Herbert Xu <[e-mail]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&amp;data=05%7C01%7CV.Sethi%40nxp.com%7C9
> df35ead51ad4143067e08da9572d5d5%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637986617695149505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=t5RXelrFDZZ7GdMyZeLcSR2hRN6O0Hs8uI2MpIwhCms
> %3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7CV.Sethi%40nxp.
> com%7C9df35ead51ad4143067e08da9572d5d5%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637986617695149505%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&amp;sdata=V7NXYx5pYPjte6jlw1gpYCBPftJBZGpHBN44
> e3pD0ps%3D&amp;reserved=0

Patch

diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 2324ab6f1846..b4fa83ca87bd 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -639,6 +639,8 @@  struct crypto_tfm {
 
 	u32 crt_flags;
 
+	unsigned int is_hbk;
+
 	int node;
 	
 	void (*exit)(struct crypto_tfm *tfm);