Re: PBKDF2 support in the linux kernel

[Herbert Xu]

On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote:
> Hi all,
> The request is that, we'd like to generate a symmetric key derived from
> user provided passphase(not rely on any third-party library). May I know if
> there is a PBKDF2(Password-Based Key Derivation Function 2) support in the
> kernel? (https://tools.ietf.org/html/rfc2898#5.2)
> We have hmac sha1 in the kernel, do we have plan to port/implement
> corresponding PBKDF2 in the kernel too?

The rule for adding crypto code to the kernel is simple, there
must be an in-kernel user of the algorithm.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCHv2 1/2] crypto: ccp: Add DOWNLOAD_FIRMWARE SEV command

[Janakarajan Natarajan]

The DOWNLOAD_FIRMWARE command, added as of SEV API v0.15, allows the OS
to install SEV firmware newer than the currently active SEV firmware.

For the new SEV firmware to be applied it must:
* Pass the validation test performed by the existing firmware.
* Be of the same build or a newer build compared to the existing firmware.

For more information please refer to "Section 5.11 DOWNLOAD_FIRMWARE" of
https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf

Signed-off-by: Janakarajan Natarajan 
---
 drivers/crypto/ccp/psp-dev.c | 99 +++-
 drivers/crypto/ccp/psp-dev.h |  4 ++
 include/linux/psp-sev.h  | 12 ++
 3 files changed, 105 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index d95ec52..12838b4 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -22,11 +22,17 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sp-dev.h"
 #include "psp-dev.h"
 
+#define SEV_VERSION_GREATER_OR_EQUAL(_maj, _min)   \
+   ((psp_master->api_major) >= _maj && \
+(psp_master->api_minor) >= _min)
+
 #define DEVICE_NAME"sev"
+#define SEV_FW_FILE"amd/sev.fw"
 
 static DEFINE_MUTEX(sev_cmd_mutex);
 static struct sev_misc_dev *misc_dev;
@@ -112,6 +118,7 @@ static int sev_cmd_buffer_len(int cmd)
case SEV_CMD_RECEIVE_UPDATE_DATA:   return sizeof(struct 
sev_data_receive_update_data);
case SEV_CMD_RECEIVE_UPDATE_VMSA:   return sizeof(struct 
sev_data_receive_update_vmsa);
case SEV_CMD_LAUNCH_UPDATE_SECRET:  return sizeof(struct 
sev_data_launch_secret);
+   case SEV_CMD_DOWNLOAD_FIRMWARE: return sizeof(struct 
sev_data_download_firmware);
default:return 0;
}
 
@@ -378,6 +385,79 @@ void *psp_copy_user_blob(u64 __user uaddr, u32 len)
 }
 EXPORT_SYMBOL_GPL(psp_copy_user_blob);
 
+static int sev_get_api_version(void)
+{
+   struct sev_user_data_status *status;
+   int error, ret;
+
+   status = _master->status_cmd_buf;
+   ret = sev_platform_status(status, );
+   if (ret) {
+   dev_err(psp_master->dev,
+   "SEV: failed to get status. Error: %#x\n", error);
+   return 1;
+   }
+
+   psp_master->api_major = status->api_major;
+   psp_master->api_minor = status->api_minor;
+   psp_master->build = status->build;
+
+   return 0;
+}
+
+/* Don't fail if SEV FW couldn't be updated. Continue with existing SEV FW */
+static int sev_update_firmware(struct device *dev)
+{
+   struct sev_data_download_firmware *data;
+   const struct firmware *firmware;
+   int ret, error, order;
+   struct page *p;
+   u64 data_size;
+
+   ret = request_firmware(, SEV_FW_FILE, dev);
+   if (ret < 0)
+   return -1;
+
+   /*
+* SEV FW expects the physical address given to it to be 32
+* byte aligned. Memory allocated has structure placed at the
+* beginning followed by the firmware being passed to the SEV
+* FW. Allocate enough memory for data structure + alignment
+* padding + SEV FW.
+*/
+   data_size = ALIGN(sizeof(struct sev_data_download_firmware), 32);
+
+   order = get_order(firmware->size + data_size);
+   p = alloc_pages(GFP_KERNEL, order);
+   if (!p) {
+   ret = -1;
+   goto fw_err;
+   }
+
+   /*
+* Copy firmware data to a kernel allocated contiguous
+* memory region.
+*/
+   data = page_address(p);
+   memcpy(page_address(p) + data_size, firmware->data, firmware->size);
+
+   data->address = __psp_pa(page_address(p) + data_size);
+   data->len = firmware->size;
+
+   ret = sev_do_cmd(SEV_CMD_DOWNLOAD_FIRMWARE, data, );
+   if (ret)
+   dev_dbg(dev, "Failed to update SEV firmware: %#x\n", error);
+   else
+   dev_info(dev, "SEV firmware update successful\n");
+
+   __free_pages(p, order);
+
+fw_err:
+   release_firmware(firmware);
+
+   return ret;
+}
+
 static int sev_ioctl_do_pek_import(struct sev_issue_cmd *argp)
 {
struct sev_user_data_pek_cert_import input;
@@ -750,7 +830,6 @@ EXPORT_SYMBOL_GPL(sev_issue_cmd_external_user);
 
 void psp_pci_init(void)
 {
-   struct sev_user_data_status *status;
struct sp_device *sp;
int error, rc;
 
@@ -760,6 +839,13 @@ void psp_pci_init(void)
 
psp_master = sp->psp_data;
 
+   if (sev_get_api_version())
+   goto err;
+
+   if (SEV_VERSION_GREATER_OR_EQUAL(0, 15) &&
+   sev_update_firmware(psp_master->dev) == 0)
+   sev_get_api_version();
+
/* Initialize the platform */
rc = sev_platform_init();
if (rc) {
@@ -767,16 +853,9 @@ void psp_pci_init(void)
goto err;
}
 
-   

[PATCHv2 2/2] crypto: ccp: Add GET_ID SEV command

[Janakarajan Natarajan]

The GET_ID command, added as of SEV API v0.16, allows the SEV firmware
to be queried about a unique CPU ID. This unique ID can then be used
to obtain the public certificate containing the Chip Endorsement Key
(CEK) public key signed by the AMD SEV Signing Key (ASK).

For more information please refer to "Section 5.12 GET_ID" of
https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf

Signed-off-by: Janakarajan Natarajan 
---
 drivers/crypto/ccp/psp-dev.c | 44 
 include/linux/psp-sev.h  | 11 +++
 include/uapi/linux/psp-sev.h | 12 
 3 files changed, 67 insertions(+)

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 12838b4..ff478d8 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -119,6 +119,7 @@ static int sev_cmd_buffer_len(int cmd)
case SEV_CMD_RECEIVE_UPDATE_VMSA:   return sizeof(struct 
sev_data_receive_update_vmsa);
case SEV_CMD_LAUNCH_UPDATE_SECRET:  return sizeof(struct 
sev_data_launch_secret);
case SEV_CMD_DOWNLOAD_FIRMWARE: return sizeof(struct 
sev_data_download_firmware);
+   case SEV_CMD_GET_ID:return sizeof(struct 
sev_data_get_id);
default:return 0;
}
 
@@ -510,6 +511,46 @@ static int sev_ioctl_do_pek_import(struct sev_issue_cmd 
*argp)
return ret;
 }
 
+static int sev_ioctl_do_get_id(struct sev_issue_cmd *argp)
+{
+   struct sev_data_get_id *data;
+   u64 data_size, user_size;
+   void *id_blob, *mem;
+   int ret;
+
+   /* SEV GET_ID available from SEV API v0.16 and up */
+   if (!SEV_VERSION_GREATER_OR_EQUAL(0, 16))
+   return -ENOTSUPP;
+
+   /* SEV FW expects the buffer it fills with the ID to be
+* 8-byte aligned. Memory allocated should be enough to
+* hold data structure + alignment padding + memory
+* where SEV FW writes the ID.
+*/
+   data_size = ALIGN(sizeof(struct sev_data_get_id), 8);
+   user_size = sizeof(struct sev_user_data_get_id);
+
+   mem = kzalloc(data_size + user_size, GFP_KERNEL);
+   if (!mem)
+   return -ENOMEM;
+
+   data = mem;
+   id_blob = mem + data_size;
+
+   data->address = __psp_pa(id_blob);
+   data->len = user_size;
+
+   ret = __sev_do_cmd_locked(SEV_CMD_GET_ID, data, >error);
+   if (!ret) {
+   if (copy_to_user((void __user *)argp->data, id_blob, data->len))
+   ret = -EFAULT;
+   }
+
+   kfree(mem);
+
+   return ret;
+}
+
 static int sev_ioctl_do_pdh_export(struct sev_issue_cmd *argp)
 {
struct sev_user_data_pdh_cert_export input;
@@ -647,6 +688,9 @@ static long sev_ioctl(struct file *file, unsigned int 
ioctl, unsigned long arg)
case SEV_PDH_CERT_EXPORT:
ret = sev_ioctl_do_pdh_export();
break;
+   case SEV_GET_ID:
+   ret = sev_ioctl_do_get_id();
+   break;
default:
ret = -EINVAL;
goto out;
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 1d24962..827c601 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -55,6 +55,7 @@ enum sev_cmd {
SEV_CMD_PDH_GEN = 0x009,
SEV_CMD_DF_FLUSH= 0x00A,
SEV_CMD_DOWNLOAD_FIRMWARE   = 0x00B,
+   SEV_CMD_GET_ID  = 0x00C,
 
/* Guest commands */
SEV_CMD_DECOMMISSION= 0x020,
@@ -142,6 +143,16 @@ struct sev_data_download_firmware {
 } __packed;
 
 /**
+ * struct sev_data_get_id - GET_ID command parameters
+ *
+ * @address: physical address of region to place unique CPU ID(s)
+ * @len: len of the region
+ */
+struct sev_data_get_id {
+   u64 address;/* In */
+   u32 len;/* In/Out */
+} __packed;
+/**
  * struct sev_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
  *
  * @pdh_address: PDH certificate address
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
index 9008f31..ac8c60b 100644
--- a/include/uapi/linux/psp-sev.h
+++ b/include/uapi/linux/psp-sev.h
@@ -30,6 +30,7 @@ enum {
SEV_PDH_GEN,
SEV_PDH_CERT_EXPORT,
SEV_PEK_CERT_IMPORT,
+   SEV_GET_ID,
 
SEV_MAX,
 };
@@ -124,6 +125,17 @@ struct sev_user_data_pdh_cert_export {
 } __packed;
 
 /**
+ * struct sev_user_data_get_id - GET_ID command parameters
+ *
+ * @socket1: Buffer to pass unique ID of first socket
+ * @socket2: Buffer to pass unique ID of second socket
+ */
+struct sev_user_data_get_id {
+   __u8 socket1[64];   /* Out */
+   __u8 socket2[64];   /* Out */
+} __packed;
+
+/**
  * struct sev_issue_cmd - SEV ioctl parameters
  *
  * @cmd: SEV commands to execute
-- 
2.7.4

[PATCHv2 0/2] Add new SEV commands

[Janakarajan Natarajan]

This patchset adds two new SEV commands, introduced in SEV API v0.15
and v0.16 respectively.

* DOWNLOAD_FIRMWARE allows the SEV firmware to be updated if a blob newer
  than or similar to the exisiting build is available.

* GET_ID allows to query for a unique ID that can be used to retrieve the
  Chip Endorsment Key (CEK) public key signed by the AMD SEV Signing Key
  (ASK). 

v1->v2:
* Added cover letter.
* Misc changes based on Boris' feedback.

Janakarajan Natarajan (2):
  crypto: ccp: Add DOWNLOAD_FIRMWARE SEV command
  crypto: ccp: Add GET_ID SEV command

 drivers/crypto/ccp/psp-dev.c | 143 ---
 drivers/crypto/ccp/psp-dev.h |   4 ++
 include/linux/psp-sev.h  |  23 +++
 include/uapi/linux/psp-sev.h |  12 
 4 files changed, 172 insertions(+), 10 deletions(-)

-- 
2.7.4

Re: PBKDF2 support in the linux kernel

[Eric Biggers]

Hi Denis,

On Fri, May 25, 2018 at 09:48:36AM -0500, Denis Kenzior wrote:
> Hi Eric,
> 
> > The solution to the "too many system calls" problem is trivial: just do 
> > SHA-512
> > in userspace.  It's just math; you don't need a system call, any more than 
> > you
> > would call sys_add(1, 1) to compute 1 + 1.  The CPU instructions that can
> > accelerate SHA-512, such as AVX and ARM CE, are available in userspace too; 
> > and
> > there are tons of libraries already available that implement it for you.  
> > Your
> > argument isn't fundamentally different from saying that sys_leftpad() (if 
> > we had
> > the extraordinary misfortune of it actually existing) is too slow, so we 
> > should
> > add a Javascript interpreter to the kernel.
> 
> So lets recap.  The Kernel crypto framework is something that:
> a) (some, many?) people are totally happy with, it does everything that they
> want
> b) is peer reviewed by the best programmers in the world
> c) responds / fixes vulnerabilities almost instantly
> d) automatically picks the best software optimized version of a given crypto
> algorithm for us
> e) automagically uses hardware optimization if the system supports it
> f) API compatibility is essentially guaranteed forever
> g) Maybe not the most performant in the world, but to many users this
> doesn't matter.
> 
> So your response to those users is to please stop using what works well and
> start adding random crypto code from the internet into their project?
> Something that likely won't do a, b, c, d, e or f above just because *oh
> gosh* we might find and have to fix some bugs in the kernel?  Have you
> actually thought through how that sounds?
> 
> What you call laziness I call 'common sense' and 'good security practice.'
> Does using the kernel make sense for everyone? No.  But for some it does.
> So if there's a legitimate way to make things better, can we not discuss
> them civilly?

I've explained this already -- it is exactly the *opposite* of good security
practice to increase the attack surface of ring 0 code.  Have *you* actually
thought about how it ridiculous it is elevate privileges just to do math?  We
need to be reducing the kernel attack surface, not increasing it.

It's great that you're confident in me, Herbert, Stephen, and other people who
contribute to the Linux crypto API.  The reality though is that there are still
known denial of service vulnerabilities that no one has found time to fix yet,
like deadlocking the kernel through recursive pcrypt, or exhausting kernel
memory by instantiating an unbounded number of crypto algorithms.  These types
of bugs aren't relevant for userspace crypto libraries as it would just be an
application shooting itself in the foot, but in the kernel they are a problem
for everyone, at least without e.g. an SELinux policy in place to lock down the
attack surface.

Again, all your arguments minus the crypto-specific parts also apply to
sys_leftpad(), which to be very clear was an April Fool's joke, and not an
actual proposal.  I trust that this wasn't meant to be a very late April Fool's
joke too :-)

> 
> > 
> > Also note that in the rare cases where the kernel actually does do very long
> > running calculations for whatever reason, kernel developers pretty regularly
> > screw it up by forgetting to insert explicit preemption points 
> > (cond_resched()),
> > or (slightly less bad) making it noninterruptible.  I had to "fix" one of 
> > these,
> > where someone for whatever reason added a keyctl() operation that does
> > Diffie-Hellman key exchange in software.  In !CONFIG_PREEMPT kernels any
> > unprivileged user could call it to lock up all CPUs for 20+ seconds, meaning
> > that no other processes can be scheduled on them.  This isn't a problem at 
> > all
> > in userspace.
> 
> And this is exactly why people should _want_ to use the kernel crypto
> framework.  Because people like you exist and fix such issues.  So again,
> kudos :)
> 

No, it's exactly why people should *not* want to do crypto in the kernel,
because that class of bug cannot exist in userspace code.

Eric

Re: PBKDF2 support in the linux kernel

[Denis Kenzior]

Hi Eric,


The solution to the "too many system calls" problem is trivial: just do SHA-512
in userspace.  It's just math; you don't need a system call, any more than you
would call sys_add(1, 1) to compute 1 + 1.  The CPU instructions that can
accelerate SHA-512, such as AVX and ARM CE, are available in userspace too; and
there are tons of libraries already available that implement it for you.  Your
argument isn't fundamentally different from saying that sys_leftpad() (if we had
the extraordinary misfortune of it actually existing) is too slow, so we should
add a Javascript interpreter to the kernel.


So lets recap.  The Kernel crypto framework is something that:
a) (some, many?) people are totally happy with, it does everything that 
they want

b) is peer reviewed by the best programmers in the world
c) responds / fixes vulnerabilities almost instantly
d) automatically picks the best software optimized version of a given 
crypto algorithm for us

e) automagically uses hardware optimization if the system supports it
f) API compatibility is essentially guaranteed forever
g) Maybe not the most performant in the world, but to many users this 
doesn't matter.


So your response to those users is to please stop using what works well 
and start adding random crypto code from the internet into their 
project?  Something that likely won't do a, b, c, d, e or f above just 
because *oh gosh* we might find and have to fix some bugs in the kernel? 
 Have you actually thought through how that sounds?


What you call laziness I call 'common sense' and 'good security 
practice.'  Does using the kernel make sense for everyone? No.  But for 
some it does.  So if there's a legitimate way to make things better, can 
we not discuss them civilly?




Also note that in the rare cases where the kernel actually does do very long
running calculations for whatever reason, kernel developers pretty regularly
screw it up by forgetting to insert explicit preemption points (cond_resched()),
or (slightly less bad) making it noninterruptible.  I had to "fix" one of these,
where someone for whatever reason added a keyctl() operation that does
Diffie-Hellman key exchange in software.  In !CONFIG_PREEMPT kernels any
unprivileged user could call it to lock up all CPUs for 20+ seconds, meaning
that no other processes can be scheduled on them.  This isn't a problem at all
in userspace.


And this is exactly why people should _want_ to use the kernel crypto 
framework.  Because people like you exist and fix such issues.  So 
again, kudos :)


Regards,
-Denis

Re: PBKDF2 support in the linux kernel

[Theodore Y. Ts'o]

On Fri, May 25, 2018 at 12:07:06PM +0200, Tomas Mraz wrote:
> 
> Because having millions of copies of SHA1, MD5, and SHA2 and  in
> millions of applications is the best thing.
>
> Now that's something I would call laziness - just copy the code and do
> not care about doing the proper decision which crypto library to use.

These algorithms are static and have test vectors.  If you don't need
hardware acceleration for your use case, and portability and reducing
external dependencies are a priority, it's a very realistic
engineering tradeoff.

libext2fs has been ABI backwards compatible for 19 years (since the
move from a.out to ELF shared libraries).  OpenSSL can't keep ABI
compatibility from one relase to another.  You can't build ABI
compatibility on top of shifting sands, so that's a really good reason
for a library not to depend on OpenSSL (if you care about backwards
compatibility, anyway).

Also consider that sha512.o is only 4735 bytes.  libxml2 has a size of
1.75 megabytes, so having my own version of sha512 is equivalent to
0.26% of libxml2.

Using my own copy of sha512?  2.5 milli-libxml2's.  Shared library ABI
backwards compatibility?  Priceless.

(And I won't even get into the bloat-o-rama which is GNOME2)

   - Ted

[bug report] crypto: chtls - Register chtls with net tls

[Dan Carpenter]

Hello Atul Gupta,

The patch a08943947873: "crypto: chtls - Register chtls with net tls"
from Mar 31, 2018, leads to the following static checker warning:

drivers/crypto/chelsio/chtls/chtls_main.c:352 chtls_recv_packet()
error: double free of 'skb'

drivers/crypto/chelsio/chtls/chtls_main.c
   337  static int chtls_recv_packet(struct chtls_dev *cdev,
   338   const struct pkt_gl *gl, const __be64 *rsp)
   339  {
   340  unsigned int opcode = *(u8 *)rsp;
   341  struct sk_buff *skb;
   342  int ret;
   343  
   344  skb = copy_gl_to_skb_pkt(gl, rsp, cdev->lldi->sge_pktshift);
   345  if (!skb)
   346  return -ENOMEM;
   347  
   348  ret = chtls_handlers[opcode](cdev, skb);
   349  if (ret & CPL_RET_BUF_DONE)
   350  kfree_skb(skb);

This is a false positive because Smatch doesn't parse the test for
CPL_RET_BUF_DONE set correctly.  It's not that complicated for me to fix
that in Smatch so I will eventually.  But really this is risky code.
A bunch of these handler functions return -EINVAL.  If they return an
odd numbered error code instead then we free skb which is pretty
subtle so far as APIs are concerned.

Looking at it now, I think we probably should be freeing skb on those
paths.  The current code looks leaky to me.

   351  
   352  return 0;
   353  }

regards,
dan carpenter

Re: PBKDF2 support in the linux kernel

[Tomas Mraz]

On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote:
> > 
> > But seriously, how is it a fault of the 'random person on the
> > mailing list'
> > that AF_ALG exists and is being used for its (seemingly intended)
> > purpose?
> > 
> > I'm not really here to criticize or judge the past.  AF_ALG exists
> > now. It
> > is being used.  Can we just make it better?  Or are we going to
> > whinge at
> > every user that tries to use (and improve) kernel features that
> > (some)
> > people disagree with because it can 'compromise' kernel security?
> 
> Another point of view is that it was arguably a mistake, and we
> shouldn't make it worse.
> 
> > > Also, if speed isn't a worry, why not just a single software-only
> > > implementation of SHA1, and be done with it?  It's what I did in
> > > e2fsprogs for e4crypt.
> > 
> > If things were that simple, we would definitely not be having this
> > exchange.
> > Lets just say we use just about every feature that crypto subsystem
> > provides
> > in some way.
> 
> What I'm saying here is if you need to code PBPDF2 in user-space, it
> _really_ isn't hard.  I've done it.  It's less than 7k of source code
> to implement SHA512:
> 
> https://ghit.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs
> /sha256.c
> 
> and then less than 50 lines of code to implement PBPDF2 (I didn't
> even
> bother putting in a library such as libext2fs):
> 
> https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/e4cryp
> t.c#n405
> 
> This is all you would need to do if we don't put PBPDF2 in the
> kernel.
> Is it really that onerous?
> 
> If you don't want to use some crypto library, I don't blame you --- I
> just grabbed the code and dropped it into e2fsprogs; so I understand
> that POV.  And so if you want to keep using AF_ALG, we made a
> mistake,
> created an attractive nuisance, and we have to support it forever.
> Fine.  But we don't have to add more _stuff_ into the kernel

Because having millions of copies of SHA1, MD5, and SHA2 and  in
millions of applications is the best thing. 

Now that's something I would call laziness - just copy the code and do
not care about doing the proper decision which crypto library to use.

LOL

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

[PATCH] Add MODULE_FIRMWARE for all qat drivers

[Conor McLoughlin]

Signed-off-by: Conor McLoughlin 
---
 drivers/crypto/qat/qat_c3xxx/adf_drv.c| 2 ++
 drivers/crypto/qat/qat_c62x/adf_drv.c | 2 ++
 drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/crypto/qat/qat_c3xxx/adf_drv.c 
b/drivers/crypto/qat/qat_c3xxx/adf_drv.c
index f172171..ba197f3 100644
--- a/drivers/crypto/qat/qat_c3xxx/adf_drv.c
+++ b/drivers/crypto/qat/qat_c3xxx/adf_drv.c
@@ -329,5 +329,7 @@ static void __exit adfdrv_release(void)
 
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_AUTHOR("Intel");
+MODULE_FIRMWARE(ADF_C3XXX_FW);
+MODULE_FIRMWARE(ADF_C3XXX_MMP);
 MODULE_DESCRIPTION("Intel(R) QuickAssist Technology");
 MODULE_VERSION(ADF_DRV_VERSION);
diff --git a/drivers/crypto/qat/qat_c62x/adf_drv.c 
b/drivers/crypto/qat/qat_c62x/adf_drv.c
index 58a984c9..59a5a0d 100644
--- a/drivers/crypto/qat/qat_c62x/adf_drv.c
+++ b/drivers/crypto/qat/qat_c62x/adf_drv.c
@@ -329,5 +329,7 @@ static void __exit adfdrv_release(void)
 
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_AUTHOR("Intel");
+MODULE_FIRMWARE(ADF_C62X_FW);
+MODULE_FIRMWARE(ADF_C62X_MMP);
 MODULE_DESCRIPTION("Intel(R) QuickAssist Technology");
 MODULE_VERSION(ADF_DRV_VERSION);
diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c 
b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
index 2ce01f0..be5c5a9 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
@@ -332,5 +332,6 @@ static void __exit adfdrv_release(void)
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_AUTHOR("Intel");
 MODULE_FIRMWARE(ADF_DH895XCC_FW);
+MODULE_FIRMWARE(ADF_DH895XCC_MMP);
 MODULE_DESCRIPTION("Intel(R) QuickAssist Technology");
 MODULE_VERSION(ADF_DRV_VERSION);
-- 
1.9.1