From francis.lebourse at sfr.fr  Fri Jan 19 11:09:00 2018
From: francis.lebourse at sfr.fr (Francis Le Bourse)
Date: Fri, 19 Jan 2018 17:09:00 +0100
Subject: omap-aes: IV not updated after encrypt/decrypt operation
Message-ID: <9dc64b09-a032-7933-d977-c70794eba501@sfr.fr>

Hi,

AES_REG_IV() registers should be read back at the end of encryption or 
decryption operations and the values returned to the caller.

Add the code and helper to do just that.

diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 49bd56f..744885b 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -97,6 +97,13 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, 
u32 offset,
                 omap_aes_write(dd, offset, *value);
  }

+static void omap_aes_read_n(struct omap_aes_dev *dd, u32 offset,
+                                       u32 *value, int count)
+{
+       for (; count--; value++, offset += 4)
+               *value = omap_aes_read(dd, offset);
+}
+
  static int omap_aes_hw_init(struct omap_aes_dev *dd)
  {
         int err;
@@ -389,6 +396,9 @@ static void omap_aes_finish_req(struct omap_aes_dev 
*dd, int err)

         pr_debug("err: %d\n", err);

+       if ((dd->flags & (FLAGS_CBC | FLAGS_CTR)) && dd->req->info)
+               omap_aes_read_n(dd, AES_REG_IV(dd, 0), dd->req->info, 4);
+
         crypto_finalize_cipher_request(dd->engine, req, err);




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/linux-crypto/attachments/20180119/c35e9eb9/attachment.html>

From francis.lebourse at sfr.fr  Fri Jan 19 11:23:40 2018
From: francis.lebourse at sfr.fr (Francis Le Bourse)
Date: Fri, 19 Jan 2018 17:23:40 +0100
Subject: omap-aes-gcm: fix corrupt output buffers
Message-ID: <8a2c0ace-72bc-7f81-4b1f-d2f69d29dbfa@sfr.fr>

Hi,

The output of the AES-GCM encryption or decryption  is corrupted if the 
buffer crosses a page boundary.
The culprit appears to be omap_crypto_cleanup(), 
scatterwalk_map_and_copy should only be called in the 
OMAP_CRYPTO_DATA_COPIED case.
Currently the copy is also done in the OMAP_CRYPTO_BAD_DATA_LENGTH, 
resulting in random kernel data in the user output buffer.

With the patch below, the operations are fine.

diff --git a/drivers/crypto/omap-crypto.c b/drivers/crypto/omap-crypto.c
index 2c42e4b..cde56ea 100644
--- a/drivers/crypto/omap-crypto.c
+++ b/drivers/crypto/omap-crypto.c
@@ -173,7 +173,7 @@ void omap_crypto_cleanup(struct scatterlist *sg, 
struct scatterlist *orig,
         buf = sg_virt(sg);
         pages = get_order(len);

-       if (orig && (flags & OMAP_CRYPTO_COPY_MASK))
+       if (orig && (flags & OMAP_CRYPTO_DATA_COPIED))
                 scatterwalk_map_and_copy(buf, orig, offset, len, 1);

         if (flags & OMAP_CRYPTO_DATA_COPIED)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/linux-crypto/attachments/20180119/d4dc2e47/attachment.html>