On 12 September 2017 at 11:07, Steffen Klassert
<steffen.klass...@secunet.com> wrote:
> On Fri, Sep 08, 2017 at 08:57:08PM +0200, Mathias Krause wrote:
>> Hi Steffen, Herbert,
>>
>> this series solves multiple issues of padata I ran into while trying to
>
we're not switching CPUs for a given padata object by tracking
the CPU within the padata object. If the serial callback gets called on
the wrong CPU, defer invoking padata_reorder() via a kernel worker on
the CPU we're expected to run on.
Signed-off-by: Mathias Krause <mini...@googlemail.
so by comparing the current CPU with the expected target CPU. If they
match, call padata_reorder() right away. If they differ, schedule a work
item on the target CPU that does the padata_reorder() call for us.
Signed-off-by: Mathias Krause <mini...@googlemail.com>
---
include/linux/padata.h
be waiting for the first CPU in cpumask.pcpu, i.e. cpu_index 0.
Make the '__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index'
compare in padata_get_next() fail in this case by initializing the
cpu_index member of all per-cpu parallel queues. Use -1 for unused ones.
Signed-off-by
that issue we track the CPU we're supposed to handle the
request on and ensure we'll call padata_reorder() on that CPU when
padata_do_serial() gets called -- either by already running on the
corect CPU or by deferring the call to a worker.
Please apply!
Mathias Krause (3):
padata: set cpu_index
Hi Herbert,
I'm a little bit confused on how echainiv is supposed to work. I think
it's doing a few things wrongly, I just can't decide what's actually
wrong as the intended mode of operation is unclear to me. At least,
as-is, the code isn't quite operating as advertised in the comment at
the top
On 22 June 2016 at 21:03, Stephan Mueller <smuel...@chronox.de> wrote:
> Am Mittwoch, 22. Juni 2016, 20:29:37 schrieb Mathias Krause:
>
> Hi Mathias,
>
>> Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
>> accidentally removed the minimum siz
nitialized memory by accessing data
beyond the end of the netlink message.
Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
messages to the crypto_msg_min[] array.
Fixes: 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
Cc: sta...@vger.kernel.org # v4.2
Signed-of
, thereby preventing
crypto_unregister_alg() from modifying the algorithm list during the
dump.
This bug has been detected by the PaX memory sanitize feature.
Signed-off-by: Mathias Krause <mini...@googlemail.com>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: PaX Team <pagee...@
On 18 February 2015 at 07:34, George Spelvin li...@horizon.com wrote:
It's trying to load modules named:
crypto-ccm(aes)
crypto-ccm(aes)-all
crypto-ctr(aes)
crypto-ctr(aes)-all
depmod -n doesn't show any aliases with parens in their names,
That's okay. Also that it fails to load these as
On 17 February 2015 at 04:09, George Spelvin li...@horizon.com wrote:
I discovered when (belatedly) testing 3.19-rc7 the other week that
my laptop wifi was broken and would no longer associate.
Apparently this is causing some necessary crypto algorithms to fail to
load, breaking my wifi.
This module implements variations of des3_ede only. Drop the bogus
module aliases for des.
Cc: Jussi Kivilinna jussi.kivili...@iki.fi
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/crypto/des3_ede_glue.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/crypto
MD5 is not SHA1.
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/sparc/crypto/md5_glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/crypto/md5_glue.c b/arch/sparc/crypto/md5_glue.c
index 64c7ff5f72a9
The module alias should be camellia, not aes.
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/sparc/crypto/camellia_glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/crypto/camellia_glue.c
b/arch/sparc
-generic)', which used to work
with kernels v3.18 and below.
Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.
Fixes: 5d26a105b5a7 (crypto: prefix module autoloading with crypto-)
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Mathias Krause
...@vger.kernel.org # v3.18
Signed-off-by: Mathias Krause mini...@googlemail.com
---
James, this should fix the issue for you, too -- it did for me, using
your test case. Feel free to add your 'Tested-by' if it does.
This patch should go on top of crypto-2.6.git#master as it's a fix
that needs to go to stable
Hi James,
On 11 December 2014 at 09:52, James Yonan ja...@openvpn.net wrote:
I'm seeing some anomalous results with the by8 AVX CTR optimization in
3.18.
the patch you're replying to actually *disabled* the by8 variant for
v3.17 as it had another bug related to wrong counter handling in GCM.
:
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/algapi.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 18 November 2014 01:45, Kees Cook keesc...@chromium.org wrote:
On Mon, Nov 17, 2014 at 3:20 PM, Mathias Krause mini...@googlemail.com
wrote:
On 17 November 2014 21:02, Kees Cook keesc...@chromium.org wrote:
This prefixes all crypto module loading with crypto- so we never run
the risk
by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook keesc...@chromium.org
Sorry but this doesn't build for me:
CC [M] drivers/crypto/qat/qat_common/adf_ctl_drv.o
drivers/crypto/qat/qat_common/adf_ctl_drv.c:490:21: error: expected
declaration specifiers
On 17 November 2014 21:02, Kees Cook keesc...@chromium.org wrote:
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off
to propagate the fix.
Please apply!
Thanks,
Mathias
Mathias Krause (3):
crypto: aesni - fix counter overflow handling in by8 variant
crypto: aesni - remove unused defines in by8 variant
Revert crypto: aesni - disable by8 AVX CTR optimization
arch/x86/crypto/aes_ctrby8_avx-x86_64.S | 20
This reverts commit 7da4b29d496b1389d3a29b55d3668efecaa08ebd.
Now, that the issue is fixed, we can re-enable the code.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Chandramouli Narayanan mo...@linux.intel.com
---
arch/x86/crypto/aesni-intel_glue.c |4 ++--
1 file changed, 2
as expected.
Tested-by: Romain Francoise rom...@orebokech.com
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Chandramouli Narayanan mo...@linux.intel.com
---
arch/x86/crypto/aes_ctrby8_avx-x86_64.S | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git
The defines for xkey3, xkey6 and xkey9 are not used in the code. They're
probably left overs from merging the three source files for 128, 192 and
256 bit AES. They can safely be removed.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Chandramouli Narayanan mo...@linux.intel.com
On 25 September 2014 00:23, chandramouli narayanan
mo...@linux.intel.com wrote:
On Mon, 2014-09-22 at 00:28 +0200, Mathias Krause wrote:
What might be worth noting, the failing test uses an IV value of
\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFD,
or, in other words
. This makes it fail the cryptomgr test #4 that
specifically tests this corner case.
As we're quite late in the release cycle, just disable the by8 variant
for now.
Reported-by: Romain Francoise rom...@orebokech.com
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Chandramouli Narayanan mo
On 17 September 2014 13:29, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Sep 16, 2014 at 10:01:07PM +0200, Romain Francoise wrote:
On Mon, Sep 15, 2014 at 10:36:46AM +0200, Romain Francoise wrote:
I upgraded from v3.16 to v3.17-rc5 and the ctr-aes-aesni encryption test
fails, which
On 16 September 2014 22:01, Romain Francoise rom...@orebokech.com wrote:
On Mon, Sep 15, 2014 at 10:36:46AM +0200, Romain Francoise wrote:
I upgraded from v3.16 to v3.17-rc5 and the ctr-aes-aesni encryption test
fails, which makes my IPsec tunnels unhappy (see trace below). Before I
start
On 17 September 2014 22:10, Mathias Krause mini...@googlemail.com wrote:
On 16 September 2014 22:01, Romain Francoise rom...@orebokech.com wrote:
On Mon, Sep 15, 2014 at 10:36:46AM +0200, Romain Francoise wrote:
I upgraded from v3.16 to v3.17-rc5 and the ctr-aes-aesni encryption test
fails
On Wed, Jul 30, 2014 at 06:47:01PM +0200, Borislav Petkov wrote:
Building current kernel with some old toolchain (gcc 4.1.2 and gas 2.17)
chokes with:
arch/x86/crypto/crc32c-pcl-intel-asm_64.S: Assembler messages:
arch/x86/crypto/crc32c-pcl-intel-asm_64.S:128: Error: no such instruction:
On Wed, Jul 30, 2014 at 11:19:37PM +0200, Mathias Krause wrote:
On Wed, Jul 30, 2014 at 06:47:01PM +0200, Borislav Petkov wrote:
[...]
This looks too complicated. We do have as-instr for exactly those kind
of tests. And, in fact, looking at arch/x86/Makefile we already have one
for crc32
On 31 July 2014 00:11, Borislav Petkov b...@alien8.de wrote:
On Wed, Jul 30, 2014 at 11:28:14PM +0200, Mathias Krause wrote:
Gah, CONFIG_AS_CRC32 gets defined as a preprocessor symbol only so
cannot be used in makefiles. So crc32c-pcl-intel-asm_64.S needs a
#ifdef CONFIG_AS_CRC32 guard
On 9 June 2014 19:41, chandramouli narayanan mo...@linux.intel.com wrote:
[...]
@@ -1493,6 +1521,14 @@ static int __init aesni_init(void)
aesni_gcm_enc_tfm = aesni_gcm_enc;
aesni_gcm_dec_tfm = aesni_gcm_dec;
}
+ aesni_ctr_enc_tfm = aesni_ctr_enc;
= aesni_ctr_enc_avx_tfm;
+ pr_info(AES CTR mode by8 optimization enabled\n);
+ }
+#endif
#endif
err = crypto_fpu_init();
--
1.8.2.1
Patch is
Reviewed-by: Mathias Krause mini...@googlemail.com
Thanks, Chandramouli!
Regards,
Mathias
--
To unsubscribe from this list: send
:
Reviewed-by: Mathias Krause mini...@googlemail.com
Thanks,
Mathias
--
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
On Tue, Jun 03, 2014 at 05:41:14PM -0700, chandramouli narayanan wrote:
This patch introduces by8 AES CTR mode AVX optimization inspired by
Intel Optimized IPSEC Cryptograhpic library. For additional information,
please see:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=22972
On 24 March 2014 18:29, chandramouli narayanan mo...@linux.intel.com wrote:
On Mon, 2014-03-24 at 17:10 +0100, Mathias Krause wrote:
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1
functions. Also test for the BMI1 extension in the avx2_usable() test
as the AVX2 implementation not only makes use of BMI2 but also BMI1
instructions.
Cc: Chandramouli Narayanan mo...@linux.intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Mathias Krause mini
Narayanan mo...@linux.intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/crypto/sha1_avx2_x86_64_asm.S |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto
There is really no need to page align sha1_transform_avx2. The default
alignment is just fine. This is not the hot code but only the entry
point, after all.
Cc: Chandramouli Narayanan mo...@linux.intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Mathias
is
broken in multiple ways. Fixed in patch 2. In patch 3 another issue for
code alignment is fixed.
Please apply!
Mathias Krause (3):
crypto: x86/sha1 - re-enable the AVX variant
crypto: x86/sha1 - fix stack alignment of AVX2 variant
crypto: x86/sha1 - reduce size of the AVX2 asm
.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Steffen Klassert steffen.klass...@secunet.com
---
kernel/padata.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 2abd25d79c..161402f0b5 100644
--- a/kernel/padata.c
+++ b/kernel
() instead.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Steffen Klassert steffen.klass...@secunet.com
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
---
crypto/pcrypt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/pcrypt.c
Two small RCU related fixes, lockdep complained about.
Please apply!
Mathias Krause (2):
crypto: pcrypt - Fix wrong usage of rcu_dereference()
padata: Fix wrong usage of rcu_dereference()
crypto/pcrypt.c |2 +-
kernel/padata.c |2 +-
2 files changed, 2 insertions(+), 2 deletions
On 08.10.2013 14:08, Steffen Klassert wrote:
On Wed, Oct 02, 2013 at 03:40:45PM +0200, Mathias Krause wrote:
Using a spinlock to atomically increase a counter sounds wrong -- we've
atomic_t for this!
Also move 'seq_nr' to a different cache line than 'lock' to reduce cache
line trashing
On 25.10.2013 11:26, Herbert Xu wrote:
On Fri, Oct 25, 2013 at 10:20:48AM +0200, Mathias Krause wrote:
On 08.10.2013 14:08, Steffen Klassert wrote:
On Wed, Oct 02, 2013 at 03:40:45PM +0200, Mathias Krause wrote:
Using a spinlock to atomically increase a counter sounds wrong -- we've
atomic_t
, e.g.
occupying only two instead of three cache lines.
Those changes results in a 5% performance increase on an IPsec test run
using pcrypt.
Btw. the seq_lock spinlock was never explicitly initialized -- one more
reason to get rid of it.
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
AEAD key parsing is duplicated to multiple places in the kernel. Add a
common helper function to consolidate that functionality.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
---
crypto/authenc.c
Use the common helper function crypto_authenc_extractkeys() for key
parsing. Also ensure the auth key won't overflow the hash_ctx buffer.
Cc: Jamie Iles ja...@jamieiles.com
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mathias.kra
...@davemloft.net
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
---
Not tested as I've no such hardware, nor the needed cross compiler!
drivers/crypto/ixp4xx_crypto.c | 26 +-
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto
Use the common helper function crypto_authenc_extractkeys() for key
parsing.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
---
crypto/authencesn.c | 26 --
1 files changed, 4
.
Please apply!
Mathias Krause (5):
crypto: authenc - Export key parsing helper function
crypto: authencesn - Simplify key parsing
crypto: ixp4xx - Simplify and harden key parsing
crypto: picoxcell - Simplify and harden key parsing
crypto: talitos - Simplify key parsing
crypto/authenc.c
Use the common helper function crypto_authenc_extractkeys() for key
parsing.
Cc: Kim Phillips kim.phill...@freescale.com
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
---
Not tested as I've
, e.g.
occupying only two instead of three cache lines.
Those changes results in a 5% performance increase on an IPsec test run
using pcrypt.
Btw. the seq_lock spinlock was never explicitly initialized -- one more
reason to get rid of it.
Signed-off-by: Mathias Krause mathias.kra...@secunet.com
On Wed, Apr 10, 2013 at 8:26 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Wed, Apr 10, 2013 at 08:21:51AM +0200, Mathias Krause wrote:
On Wed, Apr 10, 2013 at 5:31 AM, Herbert Xu herb...@gondor.apana.org.au
wrote:
On Sun, Apr 07, 2013 at 02:05:39PM +0200, Mathias Krause wrote
There is no need to modify the netlink dispatch table at runtime and
making it const even makes the resulting object file slightly smaller.
Cc: Steffen Klassert steffen.klass...@secunet.com
Signed-off-by: Mathias Krause mini...@googlemail.com
---
crypto/crypto_user.c |4 ++--
1 file changed
On Mon, Feb 4, 2013 at 2:15 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Sun, Feb 03, 2013 at 12:09:01PM +0100, Mathias Krause wrote:
The current test for empty strings fails because it is testing the
address of a field, not a pointer. So the test will always be true.
Test
The current test for empty strings fails because it is testing the
address of a field, not a pointer. So the test will always be true.
Test for the string length instead.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: Steffen Klassert steffen.klass...@secunet.com
---
crypto
not and therefore copies random data
from behind the end of the module name, as the module name is always
shorter than CRYPTO_MAX_ALG_NAME.
Also switch to use strncpy() to copy the algorithm's name and
driver_name. They are strings, after all.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc
On Sun, Sep 09, 2012 at 12:19:58PM -0700, Herbert Xu wrote:
On Sun, Sep 09, 2012 at 11:13:02AM +0200, Romain Francoise wrote:
Still seeing this BUG with -rc5, that I originally reported here:
http://marc.info/?l=linux-crypto-vgerm=134653220530264w=2
[ 26.362567] [ cut here
On Sun, Sep 09, 2012 at 02:00:00PM -0700, Herbert Xu wrote:
On Sun, Sep 09, 2012 at 10:09:10PM +0200, Mathias Krause wrote:
It happens with the C variants of SHA1 and AES, too. You can easily
trigger the bug with Steffen's crconf[1]:
$ crconf add alg authenc(hmac(sha1-generic),cbc(aes
On Thu, May 31, 2012 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Wed, May 30, 2012 at 01:43:08AM +0200, Mathias Krause wrote:
The 32 bit variant of cbc(aes) decrypt is using instructions requiring
128 bit aligned memory locations but fails to ensure this constraint in
the code
to aesni.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43223
Reported-by: Daniel gark...@mailueberfall.de
Cc: sta...@kernel.org [v2.6.39+]
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/crypto/aesni-intel_asm.S |6 --
1 file changed, 4 insertions(+), 2
-off-by: Mathias Krause mini...@googlemail.com
---
This should be applied to cryptodev-2.6.git after it contains the above
mentioned commit, e.g. after cryptodev-2.6.git rebased to/merged v3.5-rc1.
arch/x86/crypto/Makefile |7 ---
arch/x86/crypto/sha1_ssse3_asm.S |2 +-
arch
On Fri, Aug 5, 2011 at 9:49 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Thu, Aug 04, 2011 at 08:19:23PM +0200, Mathias Krause wrote:
This patch series adds an assembler implementation for the SHA1 hash
algorithm
for the x86-64 architecture. Its raw hash performance can be more than 2
Hi Max,
2011/8/8 Locktyukhin, Maxim maxim.locktyuk...@intel.com:
I'd like to note that at Intel we very much appreciate Mathias effort to
port/integrate this implementation into Linux kernel!
$0.02 re tcrypt perf numbers below: I believe something must be terribly
broken with the tcrypt
On Thu, Aug 11, 2011 at 4:50 PM, Andy Lutomirski l...@mit.edu wrote:
I have vague plans to clean up extended state handling and make
kernel_fpu_begin work efficiently from any context. (i.e. the first
kernel_fpu_begin after a context switch could take up to ~60 ns on Sandy
Bridge, but further
On Thu, Aug 4, 2011 at 8:44 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Sun, Jul 24, 2011 at 07:53:14PM +0200, Mathias Krause wrote:
With this algorithm I was able to increase the throughput of a single
IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
the SSSE3
On Thu, Aug 4, 2011 at 7:05 PM, Mathias Krause mini...@googlemail.com wrote:
It does. Just have a look at how fpu_available() is implemented:
read: irq_fpu_usable()
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More
:
- fixed typo in Makefile making AVX version unusable
- whitespace fixes for the .S file
Regards,
Mathias
Mathias Krause (2):
crypto, sha1: export sha1_update for reuse
crypto, x86: SSSE3 based SHA1 implementation for x86-64
arch/x86/crypto/Makefile |8 +
arch/x86/crypto
for an FPU context while executing in IRQ context.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
crypto/sha1_generic.c |9 +
include/crypto/sha.h |3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/crypto/sha1_generic.c b/crypto/sha1_generic.c
index 0416091
-by: Mathias Krause mini...@googlemail.com
Cc: Maxim Locktyukhin maxim.locktyuk...@intel.com
---
arch/x86/crypto/Makefile |8 +
arch/x86/crypto/sha1_ssse3_asm.S | 558 +
arch/x86/crypto/sha1_ssse3_glue.c | 240
arch/x86/include/asm
On Sat, Jul 30, 2011 at 3:46 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Thu, Jul 28, 2011 at 05:29:35PM +0200, Mathias Krause wrote:
On Thu, Jul 28, 2011 at 4:58 PM, Herbert Xu herb...@gondor.apana.org.au
wrote:
On Sun, Jul 24, 2011 at 07:53:13PM +0200, Mathias Krause wrote
On Thu, Jul 28, 2011 at 4:58 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Sun, Jul 24, 2011 at 07:53:13PM +0200, Mathias Krause wrote:
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index 069e85b..7c46d0c 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
On Sat, Jul 16, 2011 at 2:44 PM, Mathias Krause mini...@googlemail.com wrote:
diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index c04f1b7..a80be92 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CRYPTO_AES_NI_INTEL
unusable
- whitespace fixes for the .S file
Regards,
Mathias
Mathias Krause (2):
crypto, sha1: export sha1_update for reuse
crypto, x86: SSSE3 based SHA1 implementation for x86-64
arch/x86/crypto/Makefile |8 +
arch/x86/crypto/sha1_ssse3_asm.S | 558
for an FPU context while executing in IRQ context.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
crypto/sha1_generic.c |9 +
include/crypto/sha.h |5 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/crypto/sha1_generic.c b/crypto/sha1_generic.c
index 0416091
-by: Mathias Krause mini...@googlemail.com
Cc: Maxim Locktyukhin maxim.locktyuk...@intel.com
---
arch/x86/crypto/Makefile |8 +
arch/x86/crypto/sha1_ssse3_asm.S | 558 +
arch/x86/crypto/sha1_ssse3_glue.c | 240
arch/x86/include/asm
for an FPU context while executing in IRQ context.
Signed-off-by: Mathias Krause mini...@googlemail.com
---
crypto/sha1_generic.c |9 +
include/crypto/sha.h |5 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/crypto/sha1_generic.c b/crypto/sha1_generic.c
index 0416091
-by: Mathias Krause mini...@googlemail.com
Cc: Maxim Locktyukhin maxim.locktyuk...@intel.com
---
arch/x86/crypto/Makefile |8 +
arch/x86/crypto/sha1_ssse3_asm.S | 558 +
arch/x86/crypto/sha1_ssse3_glue.c | 240
arch/x86/include/asm
no existing code.
Based on a patch by the PaX Team.
Signed-off-by: Mathias Krause mini...@googlemail.com
Cc: PaX Team pagee...@freemail.hu
---
crypto/gf128mul.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index df35e4c..5276607 100644
On 29.11.2010, 17:31 Randy Dunlap wrote:
On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
Hi all,
Changes since 20101126:
on i386 builds, I get tons of these (and more) errors:
arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
On 29.11.2010, 19:54 Randy Dunlap wrote:
On 11/29/10 10:26, Mathias Krause wrote:
On 29.11.2010, 17:31 Randy Dunlap wrote:
On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
Hi all,
Changes since 20101126:
on i386 builds, I get tons of these (and more) errors:
arch/x86/crypto
On 29.11.2010, 20:31 Randy Dunlap wrote:
On 11/29/10 11:21, Mathias Krause wrote:
On 29.11.2010, 19:54 Randy Dunlap wrote:
On 11/29/10 10:26, Mathias Krause wrote:
On 29.11.2010, 17:31 Randy Dunlap wrote:
On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
Hi all,
Changes since
On 29.11.2010, 20:31 Randy Dunlap wrote:
On 11/29/10 11:21, Mathias Krause wrote:
On 29.11.2010, 19:54 Randy Dunlap wrote:
On 11/29/10 10:26, Mathias Krause wrote:
On 29.11.2010, 17:31 Randy Dunlap wrote:
On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
Hi all,
Changes since
On 29.11.2010, 20:54 Randy Dunlap wrote:
On 11/29/10 11:45, Mathias Krause wrote:
On 29.11.2010, 20:31 Randy Dunlap wrote:
On 11/29/10 11:21, Mathias Krause wrote:
On 29.11.2010, 19:54 Randy Dunlap wrote:
On 11/29/10 10:26, Mathias Krause wrote:
On 29.11.2010, 17:31 Randy Dunlap wrote
On 29.11.2010, 21:11 Randy Dunlap wrote:
On 11/29/10 12:02, Mathias Krause wrote:
On 29.11.2010, 20:54 Randy Dunlap wrote:
On 11/29/10 11:45, Mathias Krause wrote:
On 29.11.2010, 20:31 Randy Dunlap wrote:
On 11/29/10 11:21, Mathias Krause wrote:
On 29.11.2010, 19:54 Randy Dunlap wrote
On 29.11.2010, 21:37 Randy Dunlap wrote:
On 11/29/10 12:21, Mathias Krause wrote:
On 29.11.2010, 21:11 Randy Dunlap wrote:
On 11/29/10 12:02, Mathias Krause wrote:
On 29.11.2010, 20:54 Randy Dunlap wrote:
On 11/29/10 11:45, Mathias Krause wrote:
On 29.11.2010, 20:31 Randy Dunlap wrote
-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/crypto/aesni-intel_asm.S |5 -
arch/x86/crypto/aesni-intel_glue.c | 26 +-
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S
b/arch/x86/crypto/aesni
unregister order in aesni_exit().
Signed-off-by: Mathias Krause mini...@googlemail.com
---
arch/x86/crypto/aesni-intel_asm.S |5 -
arch/x86/crypto/aesni-intel_glue.c | 26 +-
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/x86/crypto/aesni
On 13.11.2010, 00:25 Mathias Krause wrote:
On 12.11.2010, 08:34 Huang Ying wrote:
On Fri, 2010-11-12 at 15:30 +0800, Mathias Krause wrote:
On 12.11.2010, 01:33 Huang Ying wrote:
Why the improvement of ECB is so small? I can not understand it. It
should be as big as CBC.
I don't know why
On 11.11.2010, 23:20 Mathias Krause wrote:
The AES-NI instructions are also available in legacy mode so the 32-bit
architecture may profit from those, too.
To illustrate the performance gain here's a short summary of a dm-crypt
speed test on a Core i7 M620 running at 2.67GHz comparing both
On 12.11.2010, 08:34 Huang Ying wrote:
On Fri, 2010-11-12 at 15:30 +0800, Mathias Krause wrote:
On 12.11.2010, 01:33 Huang Ying wrote:
Why the improvement of ECB is so small? I can not understand it. It
should be as big as CBC.
I don't know why the ECB variant is so slow compared
Hello Huang Ying,
On 03.11.2010, 23:27 Huang Ying wrote:
On Wed, 2010-11-03 at 14:14 -0700, Mathias Krause wrote:
The AES-NI instructions are also available in legacy mode so the 32-bit
architecture may profit from those, too.
To illustrate the performance gain here's a short summary
%
Signed-off-by: Mathias Krause mini...@googlemail.com
---
v4 changes:
* adapted CBC implementation to be useable on x86, too
* redo the measurement using dm-crypt
v3 changes:
* fixed 32-bit implementation of aesni_ecb_enc (a hunk somehow moved to the end
of another function)
v2 changes:
* hide
On 12.11.2010, 01:33 Huang Ying wrote:
Hi, Mathias,
On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
All test were run five times in a row using a 256 bit key and doing i/o
to the block device in chunks of 1MB. The numbers are MB/s.
x86 (i586 variant):
1. run 2. run 3
On 12.11.2010, 08:34 Huang Ying wrote:
On Fri, 2010-11-12 at 15:30 +0800, Mathias Krause wrote:
On 12.11.2010, 01:33 Huang Ying wrote:
Hi, Mathias,
On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
All test were run five times in a row using a 256 bit key and doing i/o
to the block
On 03.11.2010, 23:27 Huang Ying wrote:
On Wed, 2010-11-03 at 14:14 -0700, Mathias Krause wrote:
The AES-NI instructions are also available in legacy mode so the 32-bit
architecture may profit from those, too.
To illustrate the performance gain here's a short summary of the tcrypt
speed test
Hi,
I modified the patch so it doesn't introduce a copy of the existing
assembler implementation but modifies the existing one to be usable for
64 and 32 bit. Additionally I added some alignment constraints for
internal functions which resulted in a noticeable speed-up.
I rerun the tests on
1 - 100 of 105 matches
Mail list logo
