<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/crypto/inside-secure/safexcel.h, branch v5.15-rc2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>crypto: sha - split sha.h into sha1.h and sha2.h</title>
<updated>2020-11-20T03:45:33+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-11-13T05:20:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a24d22b225ce158651378869a6b88105c4bdb887'/>
<id>a24d22b225ce158651378869a6b88105c4bdb887</id>
<content type='text'>
Currently &lt;crypto/sha.h&gt; contains declarations for both SHA-1 and SHA-2,
and &lt;crypto/sha3.h&gt; contains declarations for SHA-3.

This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure.  So to the extent
possible, SHA-1 shouldn't be grouped together with any of the other SHA
versions, and usage of it should be phased out.

Therefore, split &lt;crypto/sha.h&gt; into two headers &lt;crypto/sha1.h&gt; and
&lt;crypto/sha2.h&gt;, and make everyone explicitly specify whether they want
the declarations for SHA-1, SHA-2, or both.

This avoids making the SHA-1 declarations visible to files that don't
want anything to do with SHA-1.  It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Acked-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently &lt;crypto/sha.h&gt; contains declarations for both SHA-1 and SHA-2,
and &lt;crypto/sha3.h&gt; contains declarations for SHA-3.

This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure.  So to the extent
possible, SHA-1 shouldn't be grouped together with any of the other SHA
versions, and usage of it should be phased out.

Therefore, split &lt;crypto/sha.h&gt; into two headers &lt;crypto/sha1.h&gt; and
&lt;crypto/sha2.h&gt;, and make everyone explicitly specify whether they want
the declarations for SHA-1, SHA-2, or both.

This avoids making the SHA-1 declarations visible to files that don't
want anything to do with SHA-1.  It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Acked-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Reuse code in safexcel_hmac_alg_setkey</title>
<updated>2020-09-25T07:48:13+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2020-09-14T04:22:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=63cdd870ab058e750b7358a979f8baccbbdcfdcc'/>
<id>63cdd870ab058e750b7358a979f8baccbbdcfdcc</id>
<content type='text'>
The code in the current implementation of safexcel_hmac_alg_setkey
can be reused by safexcel_cipher.  This patch does just that by
renaming the previous safexcel_hmac_setkey to __safexcel_hmac_setkey.
The now-shared safexcel_hmac_alg_setkey becomes safexcel_hmac_setkey
and a new safexcel_hmac_alg_setkey has been added for use by ahash
transforms.

As a result safexcel_aead_setkey's stack frame has been reduced by
about half in size, or about 512 bytes.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The code in the current implementation of safexcel_hmac_alg_setkey
can be reused by safexcel_cipher.  This patch does just that by
renaming the previous safexcel_hmac_setkey to __safexcel_hmac_setkey.
The now-shared safexcel_hmac_alg_setkey becomes safexcel_hmac_setkey
and a new safexcel_hmac_alg_setkey has been added for use by ahash
transforms.

As a result safexcel_aead_setkey's stack frame has been reduced by
about half in size, or about 512 bytes.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Move ipad/opad into safexcel_context</title>
<updated>2020-09-25T07:48:13+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2020-09-14T04:22:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=78cf1c8bfcb81a21347dfa57ce71d475cea9f595'/>
<id>78cf1c8bfcb81a21347dfa57ce71d475cea9f595</id>
<content type='text'>
As both safexcel_ahash_ctx and safexcel_cipher_ctx contain ipad
and opad buffers this patch moves them into the common struct
safexcel_context.  It also adds a union so that they can be accessed
in the appropriate endian without crazy casts.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As both safexcel_ahash_ctx and safexcel_cipher_ctx contain ipad
and opad buffers this patch moves them into the common struct
safexcel_context.  It also adds a union so that they can be accessed
in the appropriate endian without crazy casts.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Move priv pointer into safexcel_context</title>
<updated>2020-09-25T07:48:12+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2020-09-14T04:22:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=18e5189535910450f6cf7a63f8f0b84153b91f66'/>
<id>18e5189535910450f6cf7a63f8f0b84153b91f66</id>
<content type='text'>
This patch moves the priv pointer into struct safexcel_context
because both structs that extend safexcel_context have that pointer
as well.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch moves the priv pointer into struct safexcel_context
because both structs that extend safexcel_context have that pointer
as well.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Add support for EIP197 with output classifier</title>
<updated>2020-09-18T07:20:12+00:00</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pvanleeuwen@rambus.com</email>
</author>
<published>2020-09-11T07:46:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dbc756fcf7f3b843a3c96ac4d9522a86a757ae58'/>
<id>dbc756fcf7f3b843a3c96ac4d9522a86a757ae58</id>
<content type='text'>
This patch adds support for EIP197 instances that include the output
classifier (OCE) option, as used by one of our biggest customers.
The OCE normally requires initialization and dedicated firmware, but
for the simple operations supported by this driver, we just bypass it
completely for now (using what is formally a debug feature).

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Acked-by: Antoine Tenart &lt;antoine.tenart@bootlin.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for EIP197 instances that include the output
classifier (OCE) option, as used by one of our biggest customers.
The OCE normally requires initialization and dedicated firmware, but
for the simple operations supported by this driver, we just bypass it
completely for now (using what is formally a debug feature).

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Acked-by: Antoine Tenart &lt;antoine.tenart@bootlin.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - irq balance</title>
<updated>2020-07-31T08:08:59+00:00</updated>
<author>
<name>Sven Auhagen</name>
<email>Sven.Auhagen@voleatech.de</email>
</author>
<published>2020-07-21T04:37:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c6720415907f21b9c53efbe679b96c3cc9d06404'/>
<id>c6720415907f21b9c53efbe679b96c3cc9d06404</id>
<content type='text'>
Balance the irqs of the inside secure driver over all
available cpus.
Currently all interrupts are handled by the first CPU.

From my testing with IPSec AES-GCM 256
on my MCbin with 4 Cores I get a 50% speed increase:

Before the patch: 99.73 Kpps
With the patch: 151.25 Kpps

Signed-off-by: Sven Auhagen &lt;sven.auhagen@voleatech.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Balance the irqs of the inside secure driver over all
available cpus.
Currently all interrupts are handled by the first CPU.

From my testing with IPSec AES-GCM 256
on my MCbin with 4 Cores I get a 50% speed increase:

Before the patch: 99.73 Kpps
With the patch: 151.25 Kpps

Signed-off-by: Sven Auhagen &lt;sven.auhagen@voleatech.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix Unable to fit even 1 command desc error w/ EIP97</title>
<updated>2019-12-20T06:58:33+00:00</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-12-11T16:32:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=098e51e517bc2e5865c520f3eee8bf83dd320e61'/>
<id>098e51e517bc2e5865c520f3eee8bf83dd320e61</id>
<content type='text'>
Due to the additions of support for modes like AES-CCM and AES-GCM, which
require large command tokens, the size of the descriptor has grown such that
it now does not fit into the descriptor cache of a standard EIP97 anymore.
This means that the driver no longer works on the Marvell Armada 3700LP chip
(as used on e.g. Espressobin) that it has always supported.
Additionally, performance on EIP197's like Marvell A8K may also degrade
due to being able to fit less descriptors in the on-chip cache.
Putting these tokens into the descriptor was really a hack and not how the
design was supposed to be used - resource allocation did not account for it.

So what this patch does, is move the command token out of the descriptor.
To avoid having to allocate buffers on the fly for these command tokens,
they are stuffed in a "shadow ring", which is a circular buffer of fixed
size blocks that runs in lock-step with the descriptor ring. i.e. there is
one token block per descriptor. The descriptor ring itself is then pre-
populated with the pointers to these token blocks so these do not need to
be filled in when building the descriptors later.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Due to the additions of support for modes like AES-CCM and AES-GCM, which
require large command tokens, the size of the descriptor has grown such that
it now does not fit into the descriptor cache of a standard EIP97 anymore.
This means that the driver no longer works on the Marvell Armada 3700LP chip
(as used on e.g. Espressobin) that it has always supported.
Additionally, performance on EIP197's like Marvell A8K may also degrade
due to being able to fit less descriptors in the on-chip cache.
Putting these tokens into the descriptor was really a hack and not how the
design was supposed to be used - resource allocation did not account for it.

So what this patch does, is move the command token out of the descriptor.
To avoid having to allocate buffers on the fly for these command tokens,
they are stuffed in a "shadow ring", which is a circular buffer of fixed
size blocks that runs in lock-step with the descriptor ring. i.e. there is
one token block per descriptor. The descriptor ring itself is then pre-
populated with the pointers to these token blocks so these do not need to
be filled in when building the descriptors later.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix hangup during probing for EIP97 engine</title>
<updated>2019-11-17T00:37:29+00:00</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-11-06T15:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c3510fec6e824cd7ab75f77c80412b746928aa2b'/>
<id>c3510fec6e824cd7ab75f77c80412b746928aa2b</id>
<content type='text'>
Fixed mask used for CFSIZE and RFSIZE fields of HIA_OPTIONS register,
these were all 1 bit too wide. Which caused the probing of a standard
EIP97 to actually hang due to assume way too large descriptor FIFO's.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixed mask used for CFSIZE and RFSIZE fields of HIA_OPTIONS register,
these were all 1 bit too wide. Which caused the probing of a standard
EIP97 to actually hang due to assume way too large descriptor FIFO's.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fixed warnings on inconsistent byte order handling</title>
<updated>2019-11-01T05:33:42+00:00</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-10-22T09:01:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=13a1bb93f7b1c90099c557696951884ea7dcda34'/>
<id>13a1bb93f7b1c90099c557696951884ea7dcda34</id>
<content type='text'>
This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits for the fix to safexcel.c go to Ben Dooks.

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Reported-by: Ben Dooks &lt;ben.dooks@codethink.co.uk&gt;
Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits for the fix to safexcel.c go to Ben Dooks.

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Reported-by: Ben Dooks &lt;ben.dooks@codethink.co.uk&gt;
Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: inside-secure - Add support for the EIP196</title>
<updated>2019-10-04T15:06:19+00:00</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-09-18T10:41:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5fd39c4d96c9bcbda46960772a01d90f5f72037f'/>
<id>5fd39c4d96c9bcbda46960772a01d90f5f72037f</id>
<content type='text'>
This patch adds support for the EIP196, which is an EIP197 derivative
that has no classification hardware and a simplified record cache.

The patch has been tested with the eip196b-ie and eip197c-iewxkbc
configurations on the Xilinx VCU118 development board as well as on the
Macchiatobin board (Marvell A8K - EIP197b-ieswx), including the crypto
extra tests.

Note that this patchset applies on top of the earlier submitted
"Add support for eip197f_iewc" series.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for the EIP196, which is an EIP197 derivative
that has no classification hardware and a simplified record cache.

The patch has been tested with the eip196b-ie and eip197c-iewxkbc
configurations on the Xilinx VCU118 development board as well as on the
Macchiatobin board (Marvell A8K - EIP197b-ieswx), including the crypto
extra tests.

Note that this patchset applies on top of the earlier submitted
"Add support for eip197f_iewc" series.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
