[PATCH] crypto: algif_rng - zeroize buffer holding random data

[Stephan Mueller]

Due to the change to RNGs to always return zero in success case, the RNG
interface must zeroize the buffer with the length provided by the
caller.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
index 67f612c..a346173 100644
--- a/crypto/algif_rng.c
+++ b/crypto/algif_rng.c
@@ -87,7 +87,7 @@ static int rng_recvmsg(struct kiocb *unused, struct socket 
*sock,
return genlen;
 
err = memcpy_to_msg(msg, result, len);
-   memzero_explicit(result, genlen);
+   memzero_explicit(result, len);
 
return err ? err : len;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[Tadeusz Struk]

On 03/10/2015 09:06 PM, David Miller wrote:
>> In my opinion this is not about a single, special case, but rather
>> > about being able to support asynchronous operations on socket
>> > interface.
> Nobody used the socket AIO facility for two decades, it just
> rotted and turned out to be buggy and reference freed stack
> memory on top of that.
> 
> I am absolutely not convinced this is the only way to solve your
> problem.

Do you have any suggestion?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] omap-rng: Change RNG_CONFIG_REG to RNG_CONTROL_REG when checking and disabling TRNG

[Andre Wolokita]

In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to 
determine
whether the RNG is running. This is suspicious firstly due to the use of
RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to
RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is
repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with
RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then
written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in 
RNG_CONTROL
and disabled with another in RNG_CONFIG and these bits are mirrored in some way,
I believe that the TRNG is not really shutting off.

Apart from the strange logic, I have reason to suspect that the OMAP4 related
code in this driver is driving an Inside Secure IP hardware RNG and strongly
suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the
sampling rate of the FROs. This option is by default set to 0 and is not being
set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will
always return 0. It will remain 0 because ~(value of TRNG_MASK in control) will
always be 0, because the TRNG is never shut off. This is of course presuming
that the OMAP4 features the Inside Secure IP.

I'm interested in knowing what the guys at TI think about this, as only they
can confirm or deny the detailed structure of these registers.
---
 drivers/char/hw_random/omap-rng.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index d14dcf7..67151cb 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -236,7 +236,7 @@ static int omap4_rng_init(struct omap_rng_dev *priv)
u32 val;
 
/* Return if RNG is already running. */
-   if (omap_rng_read(priv, RNG_CONFIG_REG) & RNG_CONTROL_ENABLE_TRNG_MASK)
+   if (omap_rng_read(priv, RNG_CONTROL_REG) & RNG_CONTROL_ENABLE_TRNG_MASK)
return 0;
 
val = RNG_CONFIG_MIN_REFIL_CYCLES << RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT;
@@ -262,7 +262,7 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv)
 
val = omap_rng_read(priv, RNG_CONTROL_REG);
val &= ~RNG_CONTROL_ENABLE_TRNG_MASK;
-   omap_rng_write(priv, RNG_CONFIG_REG, val);
+   omap_rng_write(priv, RNG_CONTROL_REG, val);
 }
 
 static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

From: Tadeusz Struk 
Date: Tue, 10 Mar 2015 20:25:29 -0700

> In my opinion this is not about a single, special case, but rather
> about being able to support asynchronous operations on socket
> interface.

Nobody used the socket AIO facility for two decades, it just
rotted and turned out to be buggy and reference freed stack
memory on top of that.

I am absolutely not convinced this is the only way to solve your
problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

From: Ying Xue 
Date: Wed, 11 Mar 2015 11:18:01 +0800

> Sorry, I did not realize the case when I created the commit. However, 
> although I
> don't understand its scenario, in my opinion, adding one redundant argument 
> for
> all sockets to satisfy the special case seems unreasonable for us.

And the AIO socket mechanism was buggy and references freed up stack
objects.

That whole set of problems would need to be addressed fully before
we could even think of adding AIO support back to the socket layer.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

Because of the way you quoted the patch, it looked like a list posting
looping back to the list again, because of the "List-ID: " email header.

Therefore your posting was blocked and you'll have to resend your posting
in a way such that this doesn't happen.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[Tadeusz Struk]

On 03/10/2015 08:18 PM, Ying Xue wrote:
> Sorry, I did not realize the case when I created the commit. However, 
> although I
> don't understand its scenario, in my opinion, adding one redundant argument 
> for
> all sockets to satisfy the special case seems unreasonable for us.

In my opinion this is not about a single, special case, but rather about being 
able to support asynchronous operations on socket interface.
It is important for AF_ALG since we have crypto HW accelerators, that people 
want to access from user space, but in the future there might be other use 
cases.
Regards,
Tadeusz

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: Remove iocb argument from sendmsg and recvmsg

[Ying Xue]

Sorry, I did not realize the case when I created the commit. However, although I
don't understand its scenario, in my opinion, adding one redundant argument for
all sockets to satisfy the special case seems unreasonable for us.

Regards,
Ying

On 03/11/2015 10:37 AM, Tadeusz Struk wrote:
> Hi,
> After couple of attempts to implement an user space interface to crypto HW 
> that would meet our performance requirements, and after discussion with 
> Herbert, we have come to conclusion that using AF_ALG sockets and AIO 
> interface is the way to go.
> Unfortunately it looks like AIO operations will no longer be supported on 
> sockets because of the commit 1b784140474e4fc94281a49e96c67d29df0efbde.
> My question is why do we want to abandon AIO support in the socket layer? Is 
> it not worth keeping it for scenarios like this?
> Do we have any alternative?
> The mentioned patch attached for your reference.
> Regards,
> Tadeusz
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Tue, Mar 10, 2015 at 07:00:26PM -0700, Tadeusz Struk wrote:
> On 03/09/2015 11:03 PM, Herbert Xu wrote:
> > This is a bit of a bummer.  What happened is that net-next has
> > killed the kiocb argument to sendmsg/recvmsg.  However, this
> > change is obviously not part of the crypto tree and algif_aead
> > only exists in the crypto tree.
> > 
> > So Stephen could you fix this by hand until one of them is merged
> > upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
> 
> So does it mean that aio operations will not be supported on sockets?

Indeed.  If you want to have this ability you'll need to take
the discussion over to netdev.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build warnings after merge of the crypto tree

[Tadeusz Struk]

On 03/09/2015 11:03 PM, Herbert Xu wrote:
> This is a bit of a bummer.  What happened is that net-next has
> killed the kiocb argument to sendmsg/recvmsg.  However, this
> change is obviously not part of the crypto tree and algif_aead
> only exists in the crypto tree.
> 
> So Stephen could you fix this by hand until one of them is merged
> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

So does it mean that aio operations will not be supported on sockets?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Wed, Mar 11, 2015 at 11:56:37AM +1100, Stephen Rothwell wrote:
> 
> This is what I applied:
> 
> From: Stephen Rothwell 
> Date: Wed, 11 Mar 2015 11:51:30 +1100
> Subject: [PATCH] crypto: fix for sendmsg/recvmsg API change
> 
> Signed-off-by: Stephen Rothwell 

Looks good to me.  Thanks Stephen!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

Hi all,

On Tue, 10 Mar 2015 17:44:54 +1100 Stephen Rothwell  
wrote:
>
> On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu  
> wrote:
> >
> > On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the crypto tree, today's (and the past few days)
> > > linux-next build (powerpc allyesconfig) produced these warnings:
> > > 
> > > crypto/algif_aead.c:561:2: warning: initialization from incompatible 
> > > pointer type
> > >   .sendmsg = aead_sendmsg,
> > >   ^
> > > crypto/algif_aead.c:561:2: warning: (near initialization for 
> > > 'algif_aead_ops.sendmsg')
> > > crypto/algif_aead.c:563:2: warning: initialization from incompatible 
> > > pointer type
> > >   .recvmsg = aead_recvmsg,
> > >   ^
> > > crypto/algif_aead.c:563:2: warning: (near initialization for 
> > > 'algif_aead_ops.recvmsg')
> > > 
> > > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
> > 
> > This is a bit of a bummer.  What happened is that net-next has
> > killed the kiocb argument to sendmsg/recvmsg.  However, this
> > change is obviously not part of the crypto tree and algif_aead
> > only exists in the crypto tree.
> > 
> > So Stephen could you fix this by hand until one of them is merged
> > upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
> 
> No worries, I will put a merge fix patch in from tomorrow (and send you
> a copy just in case).

This is what I applied:

From: Stephen Rothwell 
Date: Wed, 11 Mar 2015 11:51:30 +1100
Subject: [PATCH] crypto: fix for sendmsg/recvmsg API change

Signed-off-by: Stephen Rothwell 
---
 crypto/algif_aead.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 527d27b023ab..001d8b5ad056 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -163,7 +163,7 @@ static void aead_data_wakeup(struct sock *sk)
rcu_read_unlock();
 }
 
-static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
+static int aead_sendmsg(struct socket *sock,
struct msghdr *msg, size_t size)
 {
struct sock *sk = sock->sk;
@@ -348,7 +348,7 @@ unlock:
return err ?: size;
 }
 
-static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
+static int aead_recvmsg(struct socket *sock,
struct msghdr *msg, size_t ignored, int flags)
 {
struct sock *sk = sock->sk;
-- 
2.1.4


-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpRpOjy4yOO6.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/2] crypto: algif - change algif_skcipher to be asynchronous

[Tadeusz Struk]

Hi Stephan,
On 03/10/2015 12:41 AM, Stephan Mueller wrote:
>> +#define GET_SREQ(areq, ctx) (struct skcipher_async_req *)((char *)areq
>> >+ \ +   crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req)))
>> >+
>> >+#define GET_REQ_SIZE(ctx) \
>> >+   crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req))
>> >+
>> >+#define GET_IV_SIZE(ctx) \
>> >+   crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(&ctx->req))
> Wouldn't be an inline function better?

This is rather an ideological question ;)

>> +INIT_LIST_HEAD(&sreq->list);
>> >+   sreq->tsg = kcalloc(tx_nents, sizeof(*sg), GFP_KERNEL);
> Why do you use kcalloc here and not kmalloc (why is there a memset 
> needed considering that sg_init_table is called?
> 

This is not only because of the list, but also because of the af_alg_sgl and 
scatterlists inside the skcipher_async_rsgl struct
I will need to zero them all anyway so it's easier to just use kcalloc().

>> +if (i == tx_nents) {
>> >+   struct scatterlist *tmp;
>> >+   int x;
>> >+   /* Ran out of tx slots in async request
>> >+* need to expand */
>> >+   tmp = kcalloc(tx_nents * 2, sizeof(*tmp),
>> >+ GFP_KERNEL);
> Why is the memory increased by a factor of two?

The scenario here is as follows - one has written some amount of data, say 64 
bytes. We have built an src sgl in skcipher_sendpage() or skcipher_sendmsg(), 
and now one is calling aio_read(), which triggers the skcipher_recvmsg_async(), 
and wants to read let's say 128 bytes. We process the first 64 bytes, and by 
process I mean we put it to the async req, and we get block on:
if (!ctx->used)
skcipher_wait_for_data(sk, flags);

Then the user writes more data, form a separate thread, and we proceed farther, 
but because we have only allocated just enough sgl space for the first 64 bytes 
of src data in the async request, we need to allocate more now. We don't know 
how much data has been requested in the aio_read() until we reach the end of 
the iov_iter, so we just want to make it big enough.

> 
> Could you please point me to the logic that limits the allocation to 
> prevent user space eating up kernel memory?

To submit an aio read request you need to provide a valid ptr & size or a valid 
iov vector. This is validated in fs/aio.c
This becomes the encryption destination buffer.
The src buffer for encryption is built in sendmsg()/sendpage() functions.
These are processed and freed every time the skcipher_recvmsg_async() is called 
or in the skcipher_async_cb().

> 
> Same as above: Why do you use kcalloc here and not kmalloc (why is there 
> a memset needed considering that sg_init_table is called?
> 

Same as above i.e. because of the af_alg_sgl and scatterlists inside the 
skcipher_async_rsgl struct.

>> >+   if (!tmp)
>> >+   goto free;
>> >+
>> >+   sg_init_table(tmp, tx_nents * 2);
>> >+   for (x = 0; x < tx_nents; x++)
>> >+   sg_set_page(&tmp[x], sg_page(&sreq-
>> >tsg[x]),
>> >+   sreq->tsg[x].length,
>> >+   sreq->tsg[x].offset);
>> >+   kfree(sreq->tsg);
> It seems I miss a point here, but the code is freeing the existing sreg-
>> >tsg scatterlist just to replace it with the scatterlist that is twice 
> as big. The kernel had to fill the scatterlist that is twice as big with 
> seemingly the same data we already filled our list with (according to 
> the sg_set_page call below).
> 
> If I understand that right, isn't that unnecessary work? Why not just 
> allocate just one chunk of memory for a scatterlist holding the new 
> data, fill it and chain it with the existing scatterlist?
> 

That's a valid point, but as I said, the situation is that someone supplied X 
bytes of plain text for encryption, and tried to read/encrypt Y bytes where Y > 
X.
At this point we don't know how big the Y is so, we can loop through the whole 
iov_iter allocating new sgls and linking them together,
or just allocate "big enough" buffer once and try to proceed until this new 
buffer runs out.
Keep in mind that this situation only occurs when one tries to read more than 
has been written, followed by a subsequent write that supplies more data.
This whole situation is far from optimal.

>> +if (list_empty(&sreq->list)) {
>> >+   rsgl = &sreq->first_sgl;
>> >+   list_add_tail(&rsgl->list, &sreq->list);
>> >+   } else {
>> >+   rsgl = kzalloc(sizeof(*rsgl), GFP_KERNEL);
> Why is kzalloc called? Shouldn't kmalloc suffice?
> 

You are correct, in this case it will be better to use kmalloc. 
af_alg_make_sg() does all the initialization.

>> +err = ctx->enc ? crypto_ablkcipher_encrypt(req) :
>> >+crypto_ablkcipher_decrypt(req);
>>

Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[Andrew Bresticker]

Hi James,

>> > +static irqreturn_t img_irq_handler(int irq, void *dev_id) {
>> > +   struct img_hash_dev *hdev = dev_id;
>> > +   u32 reg;
>> > +
>> > +   reg = img_hash_read(hdev, CR_INTSTAT);
>> > +   img_hash_write(hdev, CR_INTCLEAR, reg);
>> > +
>> > +   if (reg & CR_INT_NEW_RESULTS_SET) {
>> > +   dev_dbg(hdev->dev, "IRQ CR_INT_NEW_RESULTS_SET\n");
>> > +   if (DRIVER_FLAGS_BUSY & hdev->flags) {
>> > +   hdev->flags |= DRIVER_FLAGS_OUTPUT_READY;
>> > +   if (!(DRIVER_FLAGS_CPU & hdev->flags))
>> > +   hdev->flags |= DRIVER_FLAGS_DMA_READY;
>> > +   tasklet_schedule(&hdev->done_task);
>>
>> Since this done_task only gets scheduled from here, why not make this a
>> threaded IRQ handler and just do the work here instead of separating it
>> between a hard IRQ handler and a tasklet?
>
> What is the advantage of doing that?  i.e is this simple case worth setting 
> up an extra thread?

I believe threaded IRQ handlers are now preferred to using a hard IRQ
handler + tasklet when possible, partly because people tend to screw
up tasklet usage.

>> > +   err = PTR_ERR(hdev->io_base);
>> > +   goto hash_io_err;
>> > +   }
>> > +
>> > +   /* Write port (DMA or CPU) */
>> > +   hash_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> > +   if (!hash_res) {
>> > +   dev_err(dev, "no write port resource info\n");
>> > +   err = -ENODEV;
>> > +   goto res_err;
>> > +   }
>> > +   hdev->bus_addr = hash_res->start;
>>
>> Maybe set this after devm_ioremap_resource() succeeds and avoid the extra
>> error check?
>
> Not quite following you here - which check are you saying can be removed?

You can remove the if (hash_res) check if you set hdev->bus_addr after
devm_ioremap_resource().

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V3 2/2] Documentation: crypto: Add DT binding info for the img hw hash accelerator

[James Hartley]

Hi Andrew

> -Original Message-
> From: abres...@google.com [mailto:abres...@google.com] On Behalf Of
> Andrew Bresticker
> Sent: 06 March 2015 21:50
> To: James Hartley
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH V3 2/2] Documentation: crypto: Add DT binding info for
> the img hw hash accelerator
> 
> Hi James,
> 
> On Thu, Mar 5, 2015 at 7:01 PM, James Hartley 
> wrote:
> > This adds the binding documentation for the Imagination Technologies
> > hash accelerator that provides hardware acceleration for
> > SHA1/SHA224/SHA256/MD5 hashes.  This hardware will be present in the
> > upcoming pistachio SoC.
> >
> > Signed-off-by: James Hartley 
> 
> > diff --git a/Documentation/devicetree/bindings/crypto/img-hash.txt
> > b/Documentation/devicetree/bindings/crypto/img-hash.txt
> > new file mode 100644
> > index 000..7adc519
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/img-hash.txt
> > @@ -0,0 +1,27 @@
> > +Imagination Technologies hardware hash accelerator
> > +
> > +The hash accelerator provides hardware hashing acceleration for SHA1,
> > +SHA224, SHA256 and MD5 hashes
> > +
> > +Required properties:
> > +
> > +- compatible : "img,hash-accelerator"
> > +- reg : Offset and length of the register set for the module, and the
> > +DMA port
> > +- interrupts : The designated IRQ line for the hashing module.
> > +- dmas : DMA specifier as per
> > +Documentation/devicetree/bindings/dma/dma.txt
> > +- dma-names : Should be "tx"
> > +- clocks : Clock specifiers
> > +- clock-names : "hash_clk" Used to clock data through the accelerator
> > +   "hash_reg_clk" Used to clock the hash block registers
> 
> For the other IMG drivers that have been submitted, we've been  using "sys"
> as the name for the register gate clock.  Maybe we should do that here too to
> be consistent?

Yes, good idea

> 
> > +Example:
> > +
> > +   hash: hash@18149600 {
> > +   compatible = "img,hash-accelerator";
> > +   reg = <0x18149600 0x100, 0x18101100 0x4>;
> > +   interrupts = ;
> > +   dmas = <&dma 8 0x>;
> > +   dma-names = "tx";
> > +   clocks = <&cr_periph SYS_CLK_HASH>, <&clk_periph
> PERIPH_CLK_ROM>;
> > +   clock-names = "hash_clk, hash_reg_clk";
> 
> I think these are flipped (and you're missing some quotation marks).

Fixed. 

> 
> Otherwise this looks good to me.
> 
> -Andrew

Thanks for the review,

James

RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[James Hartley]

Hi Andrew

> -Original Message-
> From: abres...@google.com [mailto:abres...@google.com] On Behalf Of
> Andrew Bresticker
> Sent: 09 March 2015 05:42
> To: James Hartley
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
> accelerator
> 
> Hi James,
> 
> On Thu, Mar 5, 2015 at 7:01 PM, James Hartley 
> wrote:
> > This adds support for the Imagination Technologies hash accelerator
> > which provides hardware acceleration for
> > SHA1 SHA224 SHA256 and MD5 hashes.
> >
> > Signed-off-by: James Hartley 
> 
> Some general comments below, I'll leave review of the crypto-specific stuff to
> Herbert.
> 
> > diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index
> > 3924f93..fb84be7 100644
> > --- a/drivers/crypto/Makefile
> > +++ b/drivers/crypto/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/
> >  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/
> >  obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
> >  obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
> > +obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
> >  obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
> >  obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
> >  obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o @@ -25,3 +26,4 @@
> > obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
> >  obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
> >  obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
> >  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> > +obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
> 
> Unrelated change - perhaps a bad merge conflict resolution?

Yep, now resolved, thanks.

> 
> > diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c new
> > file mode 100644 index 000..94a3a6f
> > --- /dev/null
> > +++ b/drivers/crypto/img-hash.c
> > @@ -0,0 +1,1037 @@
> > +/*
> > + * Copyright (c) 2014 Imagination Technologies
> > + * Authors:  Will Thomas, James Hartley
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > +published
> > + * by the Free Software Foundation.
> > + *
> > + * Interface structure taken from omap-sham driver
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define CR_RESET   0
> > +#define CR_RESET_SET   1
> > +#define CR_RESET_UNSET 0
> > +
> > +#define CR_MESSAGE_LENGTH_H0x4
> > +#define CR_MESSAGE_LENGTH_L0x8
> > +
> > +#define CR_CONTROL 0xc
> > +#define CR_CONTROL_BYTE_ORDER_3210 0
> > +#define CR_CONTROL_BYTE_ORDER_0123 1
> > +#define CR_CONTROL_BYTE_ORDER_2310 2
> > +#define CR_CONTROL_BYTE_ORDER_1032 3
> > +#define CR_CONTROL_BYTE_ORDER_SHIFT8
> > +#define CR_CONTROL_ALGO_MD50
> > +#define CR_CONTROL_ALGO_SHA1   1
> > +#define CR_CONTROL_ALGO_SHA224 2
> > +#define CR_CONTROL_ALGO_SHA256 3
> > +
> > +#define CR_INTSTAT 0x10
> > +#define CR_INTENAB 0x14
> > +#define CR_INTCLEAR0x18
> > +#define CR_INT_RESULTS_AVAILABLE   BIT(0)
> > +#define CR_INT_NEW_RESULTS_SET BIT(1)
> > +#define CR_INT_RESULT_READ_ERR BIT(2)
> > +#define CR_INT_MESSAGE_WRITE_ERROR BIT(3)
> > +#define CR_INT_STATUS  BIT(8)
> > +
> > +#define CR_RESULT_QUEUE0x1c
> > +#define CR_RSD00x40
> > +#define CR_CORE_REV0x50
> > +#define CR_CORE_DES1   0x60
> > +#define CR_CORE_DES2   0x70
> > +
> > +#define DRIVER_FLAGS_BUSY  BIT(0)
> > +#define DRIVER_FLAGS_FINAL BIT(1)
> > +#define DRIVER_FLAGS_DMA_ACTIVEBIT(2)
> > +#define DRIVER_FLAGS_OUTPUT_READY  BIT(3)
> > +#define DRIVER_FLAGS_INIT  BIT(4)
> > +#define DRIVER_FLAGS_CPU   BIT(5)
> > +#define DRIVER_FLAGS_DMA_READY BIT(6)
> > +#define DRIVER_FLAGS_ERROR BIT(7)
> > +#define DRIVER_FLAGS_SGBIT(8)
> > +#define DRIVER_FLAGS_SHA1  BIT(18)
> > +#define DRIVER_FLAGS_SHA224BIT(19)
> > +#define DRIVER_FLAGS_SHA256BIT(20)
> > +#define DRIVER_FLAGS_MD5   BIT(21)
> > +
> > +#define IMG_HASH_QUEUE_LENGTH  20
> > +#define IMG_HASH_DMA_THRESHOLD 64
> > +
> > +#ifdef __LITTLE_ENDIAN
> > +#define IMG_HASH_BYTE_ORDER(CR_CONTROL_BYTE_ORDER_3210)
> > +#else
> > +#define IMG_HASH_BYTE_ORDER(CR_CONTROL_BYTE_ORDER_0123)
> > +#endif
> 
> Unnecessary parenthesis.

Fixed

> 
> > +struct img_hash_dev;
> > +
> > +struct img_hash_request_ctx {
> > +   struct img_hash_dev *hdev;
> > +   u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> > +   unsigned long   flags;
> > +   size_t 

RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[James Hartley]

> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: 10 March 2015 09:56
> To: James Hartley
> Cc: Stephan Mueller; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ga...@codeaurora.org; Andrew Bresticker
> (abres...@chromium.org); Ezequiel Garcia; linux-crypto@vger.kernel.org
> Subject: Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
> accelerator
> 
> On Tue, Mar 10, 2015 at 09:54:49AM +, James Hartley wrote:
> >
> > > Hi Herbert, and Stephan,
> > >
> > > The difficulty here is that the driver was written by a summer
> > > placement student who has since left the company, and despite
> > > searching our internal commit logs I'm unable to find any reason why
> > > 301 and 3000 are used.  I am happy to set them to 300 if that is a
> sensible figure to use.
> 
> OK please resend the patches with that change James.

Will do, I want to address Andrew Bresticker's review comments first though.

Thanks, 
James

> 
> Thanks,
> --
> Email: Herbert Xu  Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] crypto: OCTEON MD5 bugfix + SHA modules

[Herbert Xu]

On Sun, Mar 08, 2015 at 10:07:40PM +0200, Aaro Koskinen wrote:
> Hi,
> 
> The first patch is a bug fix for OCTEON MD5 aimed for 4.0-rc cycle.

Please send such bug fixes in a separate series in future.
For this one in particular it does not appear to be critical
enough to go in straight away so I have pushed it into cryptodev
along with the rest.

> The remaining patches add SHA1/SHA256/SHA512 modules. I have tested
> these on the following OCTEON boards and CPUs with 4.0-rc2:
> 
>   D-Link DSR-1000N:   CN5010p1.1-500-SCP
>   EdgeRouter Lite:CN5020p1.1-500-SCP
>   EdgeRouter Pro: CN6120p1.1-1000-NSP
> 
> All selftests are passing. With tcrypt, I get the following numbers
> on speed compared to the generic modules:

All applied.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[Herbert Xu]

On Tue, Mar 10, 2015 at 09:54:49AM +, James Hartley wrote:
>
> > Hi Herbert, and Stephan,
> > 
> > The difficulty here is that the driver was written by a summer placement
> > student who has since left the company, and despite searching our internal
> > commit logs I'm unable to find any reason why 301 and 3000 are used.  I am
> > happy to set them to 300 if that is a sensible figure to use.

OK please resend the patches with that change James.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[James Hartley]

Resend with correct email address for Andrew Bresticker.

> -Original Message-
> From: James Hartley
> Sent: 10 March 2015 09:53
> To: 'Herbert Xu'; Stephan Mueller
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ga...@codeaurora.org; andrew.brestic...@chromium.org; Ezequiel Garcia;
> linux-crypto@vger.kernel.org
> Subject: RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
> accelerator
> 
> 
> > -Original Message-
> > From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> > Sent: 10 March 2015 09:37
> > To: Stephan Mueller
> > Cc: James Hartley; robh...@kernel.org; pawel.m...@arm.com;
> > mark.rutl...@arm.com; ga...@codeaurora.org;
> > andrew.brestic...@chromium.org; Ezequiel Garcia; linux-
> > cry...@vger.kernel.org
> > Subject: Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
> > accelerator
> >
> > On Mon, Mar 09, 2015 at 07:35:57AM +0100, Stephan Mueller wrote:
> > >
> > > >+static struct ahash_alg img_algs[] = {
> > > >+{
> > > >+.init = img_hash_init,
> > > >+.update = img_hash_update,
> > > >+.final = img_hash_final,
> > > >+.finup = img_hash_finup,
> > > >+.digest = img_hash_digest,
> > > >+.halg = {
> > > >+.digestsize = MD5_DIGEST_SIZE,
> > > >+.base = {
> > > >+.cra_name = "md5",
> > > >+.cra_driver_name = "img-md5",
> > > >+.cra_priority = 301,
> > >
> > > Just curious: why do you use such odd priorities of 301 or 3000? IMHO,
> > > all you need is a priority of more than 100 to "beat" the generic C
> > > prios. Maybe you also need to beat the standard assembler
> > > implementations which are routinely at 200 for hashes. So, a prio of
> > > 300 should suffice, should it not?
> >
> > James, can you answer Stephan's question please?
> 
> Hi Herbert, and Stephan,
> 
> The difficulty here is that the driver was written by a summer placement
> student who has since left the company, and despite searching our internal
> commit logs I'm unable to find any reason why 301 and 3000 are used.  I am
> happy to set them to 300 if that is a sensible figure to use.
> 
> Thanks for the review Stephan!
> 
> >
> > Thanks,
> > --
> > Email: Herbert Xu  Home Page:
> > http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 
> James.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[James Hartley]

> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: 10 March 2015 09:37
> To: Stephan Mueller
> Cc: James Hartley; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ga...@codeaurora.org;
> andrew.brestic...@chromium.org; Ezequiel Garcia; linux-
> cry...@vger.kernel.org
> Subject: Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash
> accelerator
> 
> On Mon, Mar 09, 2015 at 07:35:57AM +0100, Stephan Mueller wrote:
> >
> > >+static struct ahash_alg img_algs[] = {
> > >+  {
> > >+  .init = img_hash_init,
> > >+  .update = img_hash_update,
> > >+  .final = img_hash_final,
> > >+  .finup = img_hash_finup,
> > >+  .digest = img_hash_digest,
> > >+  .halg = {
> > >+  .digestsize = MD5_DIGEST_SIZE,
> > >+  .base = {
> > >+  .cra_name = "md5",
> > >+  .cra_driver_name = "img-md5",
> > >+  .cra_priority = 301,
> >
> > Just curious: why do you use such odd priorities of 301 or 3000? IMHO,
> > all you need is a priority of more than 100 to "beat" the generic C
> > prios. Maybe you also need to beat the standard assembler
> > implementations which are routinely at 200 for hashes. So, a prio of
> > 300 should suffice, should it not?
> 
> James, can you answer Stephan's question please?

Hi Herbert, and Stephan, 

The difficulty here is that the driver was written by a summer placement 
student who has since left the company, and despite searching our internal 
commit logs I'm unable to find any reason why 301 and 3000 are used.  I am 
happy to set them to 300 if that is a sensible figure to use.  

Thanks for the review Stephan!

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

James.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: AES-NI: fix memory usage in GCM decryption

[Herbert Xu]

On Sun, Mar 08, 2015 at 07:49:58PM +0100, Stephan Mueller wrote:
> The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
> in req->dst. As the destination buffer for decryption only needs to hold
> the plaintext memory but cryptlen references the input buffer holding
> (ciphertext || authentication tag), the assumption of the destination
> buffer length in RFC4106 GCM operation leads to a too large size.
> 
> This patch simply subtracts the authentication tag size from cryptlen.
> The kernel crypto API logic requires the caller to provide the
> length of (ciphertext || authentication tag) as cryptlen for the
> AEAD decryption operation. Thus, the cipher implementation must
> caculate the size of the plaintext output itself and cannot simply use
> cryptlen.
> 
> Note, this fixes a kernel crash that can be triggered from user space
> via AF_ALG(aead)  without it (simply use the libkcapi test application
> from [1] and update it to use rfc4106-gcm-aes).
> 
> [1] http://www.chronox.de/libkcapi.html
> 
> CC: Tadeusz Struk 
> Signed-off-by: Stephan Mueller 

Good catch.  However, I think the same confusion exists in the
code that allocates src which may also trigger a crash.  So could
you fix that as well?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator

[Herbert Xu]

On Mon, Mar 09, 2015 at 07:35:57AM +0100, Stephan Mueller wrote:
>
> >+static struct ahash_alg img_algs[] = {
> >+{
> >+.init = img_hash_init,
> >+.update = img_hash_update,
> >+.final = img_hash_final,
> >+.finup = img_hash_finup,
> >+.digest = img_hash_digest,
> >+.halg = {
> >+.digestsize = MD5_DIGEST_SIZE,
> >+.base = {
> >+.cra_name = "md5",
> >+.cra_driver_name = "img-md5",
> >+.cra_priority = 301,
> 
> Just curious: why do you use such odd priorities of 301 or 3000? IMHO, 
> all you need is a priority of more than 100 to "beat" the generic C 
> prios. Maybe you also need to beat the standard assembler 
> implementations which are routinely at 200 for hashes. So, a prio of 300 
> should suffice, should it not?

James, can you answer Stephan's question please?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] crypto/arm: add support for SHA-224/256 using ARMv8 Crypto Extensions

[Ard Biesheuvel]

This implements the SHA-224/256 secure hash algorithm using the AArch32
versions of the ARMv8 Crypto Extensions for SHA2.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig|   9 ++
 arch/arm/crypto/Makefile   |   2 +
 arch/arm/crypto/sha2-ce-core.S | 134 +++
 arch/arm/crypto/sha2-ce-glue.c | 203 +
 4 files changed, 348 insertions(+)
 create mode 100644 arch/arm/crypto/sha2-ce-core.S
 create mode 100644 arch/arm/crypto/sha2-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index d7bc10beb8ac..9c1478e55a40 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -37,6 +37,15 @@ config CRYPTO_SHA1_ARM_CE
  SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
  using special ARMv8 Crypto Extensions.
 
+config CRYPTO_SHA2_ARM_CE
+   tristate "SHA-224/256 digest algorithm (ARM v8 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA256
+   select CRYPTO_HASH
+   help
+ SHA-256 secure hash standard (DFIPS 180-2) implemented
+ using special ARMv8 Crypto Extensions.
+
 config CRYPTO_SHA512_ARM_NEON
tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index d92d05ba646e..4ea9f96c2782 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
+obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
@@ -15,6 +16,7 @@ sha1-arm-y:= sha1-armv4-large.o sha1_glue.o
 sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
+sha2-arm-ce-y  := sha2-ce-core.o sha2-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/sha2-ce-core.S b/arch/arm/crypto/sha2-ce-core.S
new file mode 100644
index ..96af09fe957b
--- /dev/null
+++ b/arch/arm/crypto/sha2-ce-core.S
@@ -0,0 +1,134 @@
+/*
+ * sha2-ce-core.S - SHA-224/256 secure hash using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Ard Biesheuvel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+
+   k0  .reqq7
+   k1  .reqq8
+   rk  .reqr3
+
+   ta0 .reqq9
+   ta1 .reqq10
+   tb0 .reqq10
+   tb1 .reqq9
+
+   dga .reqq11
+   dgb .reqq12
+
+   dg0 .reqq13
+   dg1 .reqq14
+   dg2 .reqq15
+
+   .macro  add_only, ev, s0
+   vmovdg2, dg0
+   .ifnb   \s0
+   vld1.32 {k\ev}, [rk, :128]!
+   .endif
+   sha256h.32  dg0, dg1, tb\ev
+   sha256h2.32 dg1, dg2, tb\ev
+   .ifnb   \s0
+   vadd.u32ta\ev, q\s0, k\ev
+   .endif
+   .endm
+
+   .macro  add_update, ev, s0, s1, s2, s3
+   sha256su0.32q\s0, q\s1
+   add_only\ev, \s1
+   sha256su1.32q\s0, q\s2, q\s3
+   .endm
+
+   .align  6
+.Lsha256_rcon:
+   .word   0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5
+   .word   0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5
+   .word   0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3
+   .word   0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174
+   .word   0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc
+   .word   0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da
+   .word   0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7
+   .word   0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967
+   .word   0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13
+   .word   0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85
+   .word   0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3
+   .word   0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070
+   .word   0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5
+   .word   0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3
+   .word   0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208
+   .word   0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+
+   /*
+* void sha

[PATCH v2 4/5] crypto/arm: AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions

[Ard Biesheuvel]

This implements the ECB, CBC, CTR and XTS asynchronous block ciphers
using the AArch32 versions of the ARMv8 Crypto Extensions for AES.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig   |   9 +
 arch/arm/crypto/Makefile  |   2 +
 arch/arm/crypto/aes-ce-core.S | 518 +
 arch/arm/crypto/aes-ce-glue.c | 520 ++
 4 files changed, 1049 insertions(+)
 create mode 100644 arch/arm/crypto/aes-ce-core.S
 create mode 100644 arch/arm/crypto/aes-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 9c1478e55a40..63588bdf3b5d 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -101,4 +101,13 @@ config CRYPTO_AES_ARM_BS
  This implementation does not rely on any lookup tables so it is
  believed to be invulnerable to cache timing attacks.
 
+config CRYPTO_AES_ARM_CE
+   tristate "Accelerated AES using ARMv8 Crypto Extensions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_ALGAPI
+   select CRYPTO_ABLK_HELPER
+   help
+ Use an implementation of AES in CBC, CTR and XTS modes that uses
+ ARMv8 Crypto Extensions
+
 endif
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 4ea9f96c2782..2514c420e8d3 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_CRYPTO_AES_ARM) += aes-arm.o
 obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
+obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
@@ -17,6 +18,7 @@ sha1-arm-neon-y   := sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 sha2-arm-ce-y  := sha2-ce-core.o sha2-ce-glue.o
+aes-arm-ce-y   := aes-ce-core.o aes-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/aes-ce-core.S b/arch/arm/crypto/aes-ce-core.S
new file mode 100644
index ..8cfa468ee570
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-core.S
@@ -0,0 +1,518 @@
+/*
+ * aes-ce-core.S - AES in CBC/CTR/XTS mode using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+   .align  3
+
+   .macro  enc_round, state, key
+   aese.8  \state, \key
+   aesmc.8 \state, \state
+   .endm
+
+   .macro  dec_round, state, key
+   aesd.8  \state, \key
+   aesimc.8\state, \state
+   .endm
+
+   .macro  enc_dround, key1, key2
+   enc_round   q0, \key1
+   enc_round   q0, \key2
+   .endm
+
+   .macro  dec_dround, key1, key2
+   dec_round   q0, \key1
+   dec_round   q0, \key2
+   .endm
+
+   .macro  enc_fround, key1, key2, key3
+   enc_round   q0, \key1
+   aese.8  q0, \key2
+   veorq0, q0, \key3
+   .endm
+
+   .macro  dec_fround, key1, key2, key3
+   dec_round   q0, \key1
+   aesd.8  q0, \key2
+   veorq0, q0, \key3
+   .endm
+
+   .macro  enc_dround_3x, key1, key2
+   enc_round   q0, \key1
+   enc_round   q1, \key1
+   enc_round   q2, \key1
+   enc_round   q0, \key2
+   enc_round   q1, \key2
+   enc_round   q2, \key2
+   .endm
+
+   .macro  dec_dround_3x, key1, key2
+   dec_round   q0, \key1
+   dec_round   q1, \key1
+   dec_round   q2, \key1
+   dec_round   q0, \key2
+   dec_round   q1, \key2
+   dec_round   q2, \key2
+   .endm
+
+   .macro  enc_fround_3x, key1, key2, key3
+   enc_round   q0, \key1
+   enc_round   q1, \key1
+   enc_round   q2, \key1
+   aese.8  q0, \key2
+   aese.8  q1, \key2
+   aese.8  q2, \key2
+   veorq0, q0, \key3
+   veorq1, q1, \key3
+   veorq2, q2, \key3
+   .endm
+
+   .macro  dec_fround_3x, key1, key2, key3
+   dec_round   q0, \key1
+   dec_round   q1, \key1
+   dec_round   q2, \key1
+   aesd.8  q0, \key2
+   aesd.8  q1, \key2
+   aesd.8  q2, \key2
+   veorq0, q0, \key3
+   veorq1, q1, \key3
+   veorq2, q2, \key3
+   .endm
+
+   .macro  do_block, dround, fround
+   cmp r3, #12 @ which key si

[PATCH v2 1/5] crypto/arm: move ARM specific Kconfig definitions to a dedicated file

[Ard Biesheuvel]

This moves all Kconfig symbols defined in crypto/Kconfig that depend
on CONFIG_ARM to a dedicated Kconfig file in arch/arm/crypto, which is
where the code that implements those features resides as well.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/Kconfig|  3 ++
 arch/arm/crypto/Kconfig | 85 +
 crypto/Kconfig  | 75 ---
 3 files changed, 88 insertions(+), 75 deletions(-)
 create mode 100644 arch/arm/crypto/Kconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9f1f09a2bc9b..e60da5ab8aec 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2167,6 +2167,9 @@ source "arch/arm/Kconfig.debug"
 source "security/Kconfig"
 
 source "crypto/Kconfig"
+if CRYPTO
+source "arch/arm/crypto/Kconfig"
+endif
 
 source "lib/Kconfig"
 
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
new file mode 100644
index ..66fe82857e99
--- /dev/null
+++ b/arch/arm/crypto/Kconfig
@@ -0,0 +1,85 @@
+
+menuconfig ARM_CRYPTO
+   bool "ARM Accelerated Cryptographic Algorithms"
+   depends on ARM
+   help
+ Say Y here to choose from a selection of cryptographic algorithms
+ implemented using ARM specific CPU features or instructions.
+
+if ARM_CRYPTO
+
+config CRYPTO_SHA1_ARM
+   tristate "SHA1 digest algorithm (ARM-asm)"
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using optimized ARM assembler.
+
+config CRYPTO_SHA1_ARM_NEON
+   tristate "SHA1 digest algorithm (ARM NEON)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA1_ARM
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using optimized ARM NEON assembly, when NEON instructions are
+ available.
+
+config CRYPTO_SHA512_ARM_NEON
+   tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA512
+   select CRYPTO_HASH
+   help
+ SHA-512 secure hash standard (DFIPS 180-2) implemented
+ using ARM NEON instructions, when available.
+
+ This version of SHA implements a 512 bit hash with 256 bits of
+ security against collision attacks.
+
+ This code also includes SHA-384, a 384 bit hash with 192 bits
+ of security against collision attacks.
+
+config CRYPTO_AES_ARM
+   tristate "AES cipher algorithms (ARM-asm)"
+   depends on ARM
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES
+   help
+ Use optimized AES assembler routines for ARM platforms.
+
+ AES cipher algorithms (FIPS-197). AES uses the Rijndael
+ algorithm.
+
+ Rijndael appears to be consistently a very good performer in
+ both hardware and software across a wide range of computing
+ environments regardless of its use in feedback or non-feedback
+ modes. Its key setup time is excellent, and its key agility is
+ good. Rijndael's very low memory requirements make it very well
+ suited for restricted-space environments, in which it also
+ demonstrates excellent performance. Rijndael's operations are
+ among the easiest to defend against power and timing attacks.
+
+ The AES specifies three key sizes: 128, 192 and 256 bits
+
+ See  for more information.
+
+config CRYPTO_AES_ARM_BS
+   tristate "Bit sliced AES using NEON instructions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES_ARM
+   select CRYPTO_ABLK_HELPER
+   help
+ Use a faster and more secure NEON based implementation of AES in CBC,
+ CTR and XTS modes
+
+ Bit sliced AES gives around 45% speedup on Cortex-A15 for CTR mode
+ and for XTS mode encryption, CBC and XTS mode decryption speedup is
+ around 25%. (CBC encryption speed is not affected by this driver.)
+ This implementation does not rely on any lookup tables so it is
+ believed to be invulnerable to cache timing attacks.
+
+endif
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 50f4da44a304..c50900b467c8 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -555,26 +555,6 @@ config CRYPTO_SHA1_SPARC64
  SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
  using sparc64 crypto instructions, when available.
 
-config CRYPTO_SHA1_ARM
-   tristate "SHA1 digest algorithm (ARM-asm)"
-   depends on ARM
-   select CRYPTO_SHA1
-   select CRYPTO_HASH
-   help
- SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
- using optimized ARM assembler.
-
-config CRYPTO_SHA1_ARM_NEON
-   tristate "SHA1 digest algorithm (ARM NEON)"
-   depends on ARM && KERNEL_MODE_NEON
-   

[PATCH v2 0/5] ARM: crypto: ARMv8 Crypto Extensions

[Ard Biesheuvel]

This is v2 of the ARM crypto series I sent out yesterday, erroneously without
a cover letter.

Patch #1 moves all the ARM specific crypto options to arch/arm/crypto/Kconfig.

Patches #2 - #5 implement SHA1, SHA-224/256, AES-ECB/CBC/CTR/XTS and GHASH,
respectively.

Changes since v1:
- fixes for BE (currently still untested)
- added alignment hints where appropriate (e,g., [rX, :128])
- various minor tweaks

There are all tested on LE using the respective tcrypt tests.

Ard Biesheuvel (5):
  crypto/arm: move ARM specific Kconfig definitions to a dedicated file
  crypto/arm: add support for SHA1 using ARMv8 Crypto Instructions
  crypto/arm: add support for SHA-224/256 using ARMv8 Crypto Extensions
  crypto/arm: AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions
  crypto/arm: add support for GHASH using ARMv8 Crypto Extensions

 arch/arm/Kconfig|   3 +
 arch/arm/crypto/Kconfig | 123 ++
 arch/arm/crypto/Makefile|   8 +
 arch/arm/crypto/aes-ce-core.S   | 518 +++
 arch/arm/crypto/aes-ce-glue.c   | 520 
 arch/arm/crypto/ghash-ce-core.S |  94 
 arch/arm/crypto/ghash-ce-glue.c | 318 
 arch/arm/crypto/sha1-ce-core.S  | 134 +++
 arch/arm/crypto/sha1-ce-glue.c  | 150 
 arch/arm/crypto/sha2-ce-core.S  | 134 +++
 arch/arm/crypto/sha2-ce-glue.c  | 203 
 crypto/Kconfig  |  75 --
 12 files changed, 2205 insertions(+), 75 deletions(-)
 create mode 100644 arch/arm/crypto/Kconfig
 create mode 100644 arch/arm/crypto/aes-ce-core.S
 create mode 100644 arch/arm/crypto/aes-ce-glue.c
 create mode 100644 arch/arm/crypto/ghash-ce-core.S
 create mode 100644 arch/arm/crypto/ghash-ce-glue.c
 create mode 100644 arch/arm/crypto/sha1-ce-core.S
 create mode 100644 arch/arm/crypto/sha1-ce-glue.c
 create mode 100644 arch/arm/crypto/sha2-ce-core.S
 create mode 100644 arch/arm/crypto/sha2-ce-glue.c

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] crypto/arm: add support for GHASH using ARMv8 Crypto Extensions

[Ard Biesheuvel]

This implements the GHASH hash algorithm (as used by the GCM AEAD
chaining mode) using the AArch32 version of the 64x64 to 128 bit
polynomial multiplication instruction (vmull.p64) that is part of
the ARMv8 Crypto Extensions.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig |  10 ++
 arch/arm/crypto/Makefile|   2 +
 arch/arm/crypto/ghash-ce-core.S |  94 
 arch/arm/crypto/ghash-ce-glue.c | 318 
 4 files changed, 424 insertions(+)
 create mode 100644 arch/arm/crypto/ghash-ce-core.S
 create mode 100644 arch/arm/crypto/ghash-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 63588bdf3b5d..d63f319924d2 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -110,4 +110,14 @@ config CRYPTO_AES_ARM_CE
  Use an implementation of AES in CBC, CTR and XTS modes that uses
  ARMv8 Crypto Extensions
 
+config CRYPTO_GHASH_ARM_CE
+   tristate "PMULL-accelerated GHASH using ARMv8 Crypto Extensions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_HASH
+   select CRYPTO_CRYPTD
+   help
+ Use an implementation of GHASH (used by the GCM AEAD chaining mode)
+ that uses the 64x64 to 128 bit polynomial multiplication (vmull.p64)
+ that is part of the ARMv8 Crypto Extensions
+
 endif
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 2514c420e8d3..9a273bd7dffd 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
 obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
+obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
@@ -19,6 +20,7 @@ sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 sha2-arm-ce-y  := sha2-ce-core.o sha2-ce-glue.o
 aes-arm-ce-y   := aes-ce-core.o aes-ce-glue.o
+ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/ghash-ce-core.S b/arch/arm/crypto/ghash-ce-core.S
new file mode 100644
index ..e643a15eadf2
--- /dev/null
+++ b/arch/arm/crypto/ghash-ce-core.S
@@ -0,0 +1,94 @@
+/*
+ * Accelerated GHASH implementation with ARMv8 vmull.p64 instructions.
+ *
+ * Copyright (C) 2015 Linaro Ltd. 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+   SHASH   .reqq0
+   SHASH2  .reqq1
+   T1  .reqq2
+   T2  .reqq3
+   MASK.reqq4
+   XL  .reqq5
+   XM  .reqq6
+   XH  .reqq7
+   IN1 .reqq7
+
+   SHASH_L .reqd0
+   SHASH_H .reqd1
+   SHASH2_L.reqd2
+   T1_L.reqd4
+   MASK_L  .reqd8
+   XL_L.reqd10
+   XL_H.reqd11
+   XM_L.reqd12
+   XM_H.reqd13
+   XH_L.reqd14
+
+   .text
+   .fpucrypto-neon-fp-armv8
+
+   /*
+* void pmull_ghash_update(int blocks, u64 dg[], const char *src,
+* struct ghash_key const *k, const char *head)
+*/
+ENTRY(pmull_ghash_update)
+   vld1.8  {SHASH}, [r3]
+   vld1.64 {XL}, [r1]
+   vmov.i8 MASK, #0xe1
+   vext.8  SHASH2, SHASH, SHASH, #8
+   vshl.u64MASK, MASK, #57
+   veorSHASH2, SHASH2, SHASH
+
+   /* do the head block first, if supplied */
+   ldr ip, [sp]
+   teq ip, #0
+   beq 0f
+   vld1.64 {T1}, [ip]
+   teq r0, #0
+   b   1f
+
+0: vld1.64 {T1}, [r2]!
+   subsr0, r0, #1
+
+1: /* multiply XL by SHASH in GF(2^128) */
+#ifndef CONFIG_CPU_BIG_ENDIAN
+   vrev64.8T1, T1
+#endif
+   vext.8  T2, XL, XL, #8
+   vext.8  IN1, T1, T1, #8
+   veorT1, T1, T2
+   veorXL, XL, IN1
+
+   vmull.p64   XH, SHASH_H, XL_H   @ a1 * b1
+   veorT1, T1, XL
+   vmull.p64   XL, SHASH_L, XL_L   @ a0 * b0
+   vmull.p64   XM, SHASH2_L, T1_L  @ (a1 + a0)(b1 + b0)
+
+   vext.8  T1, XL, XH, #8
+   veorT2, XL, XH
+   veorXM, XM, T1
+   veorXM, XM, T2
+   vmull.p64   T2, XL_L, MASK_L
+
+   v

[PATCH v2 2/5] crypto/arm: add support for SHA1 using ARMv8 Crypto Instructions

[Ard Biesheuvel]

This implements the SHA1 secure hash algorithm using the AArch32
versions of the ARMv8 Crypto Extensions for SHA1.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig|  10 +++
 arch/arm/crypto/Makefile   |   2 +
 arch/arm/crypto/sha1-ce-core.S | 134 
 arch/arm/crypto/sha1-ce-glue.c | 150 +
 4 files changed, 296 insertions(+)
 create mode 100644 arch/arm/crypto/sha1-ce-core.S
 create mode 100644 arch/arm/crypto/sha1-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 66fe82857e99..d7bc10beb8ac 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -27,6 +27,16 @@ config CRYPTO_SHA1_ARM_NEON
  using optimized ARM NEON assembly, when NEON instructions are
  available.
 
+config CRYPTO_SHA1_ARM_CE
+   tristate "SHA1 digest algorithm (ARM v8 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA1_ARM
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using special ARMv8 Crypto Extensions.
+
 config CRYPTO_SHA512_ARM_NEON
tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b48fa341648d..d92d05ba646e 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -7,12 +7,14 @@ obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
+obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
 sha1-arm-y := sha1-armv4-large.o sha1_glue.o
 sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
+sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/sha1-ce-core.S b/arch/arm/crypto/sha1-ce-core.S
new file mode 100644
index ..4aad520935d8
--- /dev/null
+++ b/arch/arm/crypto/sha1-ce-core.S
@@ -0,0 +1,134 @@
+/*
+ * sha1-ce-core.S - SHA-1 secure hash using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Ard Biesheuvel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+
+   k0  .reqq0
+   k1  .reqq1
+   k2  .reqq2
+   k3  .reqq3
+
+   ta0 .reqq4
+   ta1 .reqq5
+   tb0 .reqq5
+   tb1 .reqq4
+
+   dga .reqq6
+   dgb .reqq7
+   dgbs.reqs28
+
+   dg0 .reqq12
+   dg1a0   .reqq13
+   dg1a1   .reqq14
+   dg1b0   .reqq14
+   dg1b1   .reqq13
+
+   .macro  add_only, op, ev, rc, s0, dg1
+   .ifnb   \s0
+   vadd.u32tb\ev, q\s0, \rc
+   .endif
+   sha1h.32dg1b\ev, dg0
+   .ifb\dg1
+   sha1\op\().32   dg0, dg1a\ev, ta\ev
+   .else
+   sha1\op\().32   dg0, \dg1, ta\ev
+   .endif
+   .endm
+
+   .macro  add_update, op, ev, rc, s0, s1, s2, s3, dg1
+   sha1su0.32  q\s0, q\s1, q\s2
+   add_only\op, \ev, \rc, \s1, \dg1
+   sha1su1.32  q\s0, q\s3
+   .endm
+
+   .align  6
+.Lsha1_rcon:
+   .word   0x5a827999, 0x5a827999, 0x5a827999, 0x5a827999
+   .word   0x6ed9eba1, 0x6ed9eba1, 0x6ed9eba1, 0x6ed9eba1
+   .word   0x8f1bbcdc, 0x8f1bbcdc, 0x8f1bbcdc, 0x8f1bbcdc
+   .word   0xca62c1d6, 0xca62c1d6, 0xca62c1d6, 0xca62c1d6
+
+   /*
+* void sha1_ce_transform(int blocks, u8 const *src, u32 *state,
+*u8 *head);
+*/
+ENTRY(sha1_ce_transform)
+   /* load round constants */
+   adr ip, .Lsha1_rcon
+   vld1.32 {k0-k1}, [ip, :128]!
+   vld1.32 {k2-k3}, [ip, :128]
+
+   /* load state */
+   vld1.32 {dga}, [r2]
+   vldrdgbs, [r2, #16]
+
+   /* load partial input (if supplied) */
+   teq r3, #0
+   beq 0f
+   vld1.32 {q8-q9}, [r3]!
+   vld1.32 {q10-q11}, [r3]
+   teq r0, #0
+   b   1f
+
+   /* load input */
+0: vld1.32 {q8-q9}, [r1]!
+   vld1.32 {q10-q11}, [r1]!
+   

Re: [PATCH v2 2/2] crypto: algif - change algif_skcipher to be asynchronous

[Stephan Mueller]

Am Montag, 9. März 2015, 13:55:25 schrieb Tadeusz Struk:

Hi Tadeusz,


>The way the algif_skcipher works currently is that on sendmsg/sendpage
>it builds an sgl for the input data and then on read/recvmsg it sends
>the job for encryption putting the user to sleep till the data is
>processed. This way it can only handle one job at a given time.
>This patch changes it to be asynchronous by adding AIO support.
>
>Signed-off-by: Tadeusz Struk 
>---
> crypto/algif_skcipher.c |  233
>++- 1 file changed, 226
>insertions(+), 7 deletions(-)
>
>diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
>index 0c8a1e5..790ed35 100644
>--- a/crypto/algif_skcipher.c
>+++ b/crypto/algif_skcipher.c
>@@ -39,6 +39,7 @@ struct skcipher_ctx {
>
>   struct af_alg_completion completion;
>
>+  atomic_t inflight;
>   unsigned used;
>
>   unsigned int len;
>@@ -49,9 +50,65 @@ struct skcipher_ctx {
>   struct ablkcipher_request req;
> };
>
>+struct skcipher_async_rsgl {
>+  struct af_alg_sgl sgl;
>+  struct list_head list;
>+};
>+
>+struct skcipher_async_req {
>+  struct kiocb *iocb;
>+  struct skcipher_async_rsgl first_sgl;
>+  struct list_head list;
>+  struct scatterlist *tsg;
>+  char iv[];
>+};
>+
>+#define GET_SREQ(areq, ctx) (struct skcipher_async_req *)((char *)areq
>+ \ +  crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req)))
>+
>+#define GET_REQ_SIZE(ctx) \
>+  crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req))
>+
>+#define GET_IV_SIZE(ctx) \
>+  crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(&ctx->req))

Wouldn't be an inline function better?
>+
> #define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
> sizeof(struct scatterlist) - 1)
>
>+static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
>+{
>+  struct skcipher_async_rsgl *rsgl, *tmp;
>+  struct scatterlist *sgl;
>+  struct scatterlist *sg;
>+  int i, n;
>+
>+  list_for_each_entry_safe(rsgl, tmp, &sreq->list, list) {
>+  af_alg_free_sg(&rsgl->sgl);
>+  if (rsgl != &sreq->first_sgl)
>+  kfree(rsgl);
>+  }
>+  sgl = sreq->tsg;
>+  n = sg_nents(sgl);
>+  for_each_sg(sgl, sg, n, i)
>+  put_page(sg_page(sg));
>+
>+  kfree(sreq->tsg);
>+}
>+
>+static void skcipher_async_cb(struct crypto_async_request *req, int
>err) +{
>+  struct sock *sk = req->data;
>+  struct alg_sock *ask = alg_sk(sk);
>+  struct skcipher_ctx *ctx = ask->private;
>+  struct skcipher_async_req *sreq = GET_SREQ(req, ctx);
>+  struct kiocb *iocb = sreq->iocb;
>+
>+  atomic_dec(&ctx->inflight);
>+  skcipher_free_async_sgls(sreq);
>+  kfree(req);
>+  aio_complete(iocb, err, err);
>+}
>+
> static inline int skcipher_sndbuf(struct sock *sk)
> {
>   struct alg_sock *ask = alg_sk(sk);
>@@ -96,7 +153,7 @@ static int skcipher_alloc_sgl(struct sock *sk)
>   return 0;
> }
>
>-static void skcipher_pull_sgl(struct sock *sk, int used)
>+static void skcipher_pull_sgl(struct sock *sk, int used, int put)
> {
>   struct alg_sock *ask = alg_sk(sk);
>   struct skcipher_ctx *ctx = ask->private;
>@@ -123,8 +180,8 @@ static void skcipher_pull_sgl(struct sock *sk, int
>used)
>
>   if (sg[i].length)
>   return;
>-
>-  put_page(sg_page(sg + i));
>+  if (put)
>+  put_page(sg_page(sg + i));
>   sg_assign_page(sg + i, NULL);
>   }
>
>@@ -143,7 +200,7 @@ static void skcipher_free_sgl(struct sock *sk)
>   struct alg_sock *ask = alg_sk(sk);
>   struct skcipher_ctx *ctx = ask->private;
>
>-  skcipher_pull_sgl(sk, ctx->used);
>+  skcipher_pull_sgl(sk, ctx->used, 1);
> }
>
> static int skcipher_wait_for_wmem(struct sock *sk, unsigned flags)
>@@ -424,8 +481,149 @@ unlock:
>   return err ?: size;
> }
>
>-static int skcipher_recvmsg(struct kiocb *unused, struct socket *sock,
>-  struct msghdr *msg, size_t ignored, int 
flags)
>+static int skcipher_all_sg_nents(struct skcipher_ctx *ctx)
>+{
>+  struct skcipher_sg_list *sgl;
>+  struct scatterlist *sg;
>+  int nents = 0;
>+
>+  list_for_each_entry(sgl, &ctx->tsgl, list) {
>+  sg = sgl->sg;
>+
>+  while (!sg->length)
>+  sg++;
>+
>+  nents += sg_nents(sg);
>+  }
>+  return nents;
>+}
>+
>+static int skcipher_recvmsg_async(struct kiocb *iocb, struct socket
>*sock, + struct msghdr *msg, int flags)
>+{
>+  struct sock *sk = sock->sk;
>+  struct alg_sock *ask = alg_sk(sk);
>+  struct skcipher_ctx *ctx = ask->private;
>+  struct skcipher_sg_list *sgl;
>+  struct scatterlist *sg;
>+  struct skcipher_async_req *sreq;
>+  struct ablkcipher_request *req;
>+

Re: linux-next: build warnings after merge of the crypto tree

[Stephan Mueller]

Am Dienstag, 10. März 2015, 17:44:54 schrieb Stephen Rothwell:

Hi Stephen,

>Hi Herbert,
>
>On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu 
 wrote:
>> On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
>> > After merging the crypto tree, today's (and the past few days)
>> > linux-next build (powerpc allyesconfig) produced these warnings:
>> > 
>> > crypto/algif_aead.c:561:2: warning: initialization from
>> > incompatible pointer type> > 
>> >   .sendmsg = aead_sendmsg,
>> >   ^
>> > 
>> > crypto/algif_aead.c:561:2: warning: (near initialization for
>> > 'algif_aead_ops.sendmsg') crypto/algif_aead.c:563:2: warning:
>> > initialization from incompatible pointer type> > 
>> >   .recvmsg = aead_recvmsg,
>> >   ^
>> > 
>> > crypto/algif_aead.c:563:2: warning: (near initialization for
>> > 'algif_aead_ops.recvmsg')
>> > 
>> > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD
>> > support").> 
>> This is a bit of a bummer.  What happened is that net-next has
>> killed the kiocb argument to sendmsg/recvmsg.  However, this
>> change is obviously not part of the crypto tree and algif_aead
>> only exists in the crypto tree.
>> 
>> So Stephen could you fix this by hand until one of them is merged
>> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
>
>No worries, I will put a merge fix patch in from tomorrow (and send you
>a copy just in case).

Thank you. Let me know if I should help.


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html