* James Hsiao | 2008-10-27 18:55:32 [-0700]:
Kim suggest us submit this to linuxppc-dev for more review.
so do I
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..58b48a0 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++
are
not a multiple of 4 or the vectors can not be used due to some other
limitations that I've overseen.
Signed-off-by: Sebastian Andrzej Siewior [EMAIL PROTECTED]
---
crypto/tcrypt.c | 24
crypto/testmgr.c | 27 +
crypto/testmgr.h | 166
* Jeff Garzik | 2008-11-02 20:44:40 [-0500]:
Sebastian Andrzej Siewior wrote:
I grabed them from http://www.schneier.com/skein.html. The last test
vector
(3) in every category is currently deactivated because it failed always.
It is unlikely that I made a type because I copy+pasted
* Jeff Garzik | 2008-11-02 20:44:40 [-0500]:
Sebastian Andrzej Siewior wrote:
I grabed them from http://www.schneier.com/skein.html. The last test
vector
(3) in every category is currently deactivated because it failed always.
It is unlikely that I made a type because I copy+pasted
* Huang Ying | 2008-12-15 10:19:02 [+0800]:
Nice work. A few things:
- Did you rename the old x86 functions to avoid a clash?
So you bypass the crypto layer in case you can't handle the operation.
Does this improve the performace or just saves key strokes? Not sure
what the best
* Huang Ying | 2008-12-23 16:49:26 [+0800]:
If aes_x86_64 and aes_generic are compiled as builtin, the
initialization order is undetermined. That is, aes_x86_64 may be
initilized before aes_generic is initilized, but aes_x86_64 depends on
tables generated in aes_generic initialization code.
* Herbert Xu | 2008-12-24 15:48:51 [+1100]:
On Wed, Dec 24, 2008 at 09:43:41AM +0800, Huang Ying wrote:
I think that is not easy. Not all architecture follow the same directory
structure arch/x/crypto. And arch/x86/crypto is used by user mode
linux too.
Right, relying on link order is
* Herbert Xu | 2009-02-26 14:06:18 [+0800]:
As algorithms requiring fallbacks are a special case, we can fix
this by giving them a different module alias than the rest. Then
it's just a matter of using the right aliases according to what
algorithms we're trying to find.
Yup. I am not sure if we
* Jason | 2009-03-03 12:49:37 [-0500]:
I found the nuts and bolts starting at page 174 of [3], with registers
listed starting on page 634.
they look the same to me. The registers seem to be on the same spot, the
description is the same from what I recall.
thx,
Jason.
Sebastian
--
To
* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]:
However a SW calculation is also possible.
Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes
created by the expansion algorithm. So I picked the key expand routine
from generic aes module and just passed the crypto test for
almost everything stays the same, we need just to use the extended registers
on the bit variant.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/crypto/Kconfig |2 +-
drivers/crypto/padlock-aes.c | 13 +
2 files changed, 14 insertions(+), 1
To enable the padlock unit, two msr bits have to flipped. This is allready
done in the 32bit path and is missing in the other. Instead of copy paste
the code, I merged the 64bit part into the 32bit part. The things that
changed during the merge:
- the fixups from x86_64 (family 6, model = 15) were
there should be no difference, except
* the 64bit variant now also initializes the padlock unit.
* -c_early_init() is executed again from -c_init()
* the 64bit fixups made into 32bit path.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/x86/Kconfig.cpu
* Ingo Molnar | 2009-03-14 12:47:32 [+0100]:
thanks, looks good. We can apply #1 to -tip just fine - but a
drivers/crypto/ change should go via the crypto tree. Can the
crypto tree apply #2 without having #1 right away? [i.e. will it
still build and boot fine - even though the padlock
to crash cryptsetup with
luksOpen. Got look into this...
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1 +
drivers/crypto/mav_crypto.c | 724 +++
3 files changed
* Evgeniy Polyakov | 2009-03-18 01:42:43 [+0300]:
Hi.
Hi Evgeniy,
On Tue, Mar 17, 2009 at 10:58:44PM +0100, Sebastian Andrzej Siewior
(arm-ker...@ml.breakpoint.cc) wrote:
+struct crypto_priv {
Please use less generic names over the file.
will do.
+void __iomem *reg;
+void __iomem
* Herbert Xu | 2009-04-21 13:56:13 [+0800]:
On Tue, Apr 21, 2009 at 01:53:31PM +0800, Herbert Xu wrote:
Thanks for the report. This patch should fix the problem.
In fact, padlock-aes shouldn't have been aes-all in the first
place so I'm going to add tihs patch too.
You changed all algos
* Herbert Xu | 2009-04-21 18:53:27 [+0800]:
It was already renamed in the original patch. The problem here
is that padlock-aes was incorrectly renamed as it doesn't require
a fallback.
Right, just key computation which is not part of the crypto API.
Cheers,
--
Sebastian
--
To unsubscribe
update since last post, unfortunately not much:
- interrupt handler fix
- s/mav/mv
the dm-crypt still crashes but a few delays seem to help argh
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1
* Chuck Ebbert | 2009-06-09 10:35:33 [-0400]:
The VIA Nano has a bug that makes the padlock unit fetch extra data
during encryption operations. Add workarounds for that, and enable
the driver on x86_64.
Nice. The X86_64 padlock will make it mainline in next merge window so
I'm asking you kindly
* Ben Dooks | 2009-05-07 22:39:22 [+0100]:
Sorry for the late reply.
diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
new file mode 100644
index 000..40eb083
--- /dev/null
+++ b/drivers/crypto/mv_crypto.c
+struct req_progress {
+struct sg_mapping_iter
tree
but I've rebased this patch against the orion tree [0].
Since the driver got renamed, I'm going to send a delta if nothing else
comes up.
[0] git://git.marvell.com/orion for-rmk
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Subject: [PATCH] arm/orion5x: increment window counter
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
init register the crypto device.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/arm/mach-orion5x/common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b
* Nicolas Pitre | 2009-06-11 16:36:42 [-0400]:
Adding a revision history is good thing... I could not find the ARM tree
but I've rebased this patch against the orion tree [0].
Actually, I'm leaning towards the removal of such dynamic mappings
altogether and keep an unconditional static
* Nicolas Pitre | 2009-06-11 17:19:22 [-0400]:
What is your plan for this driver? Submit it now and add incremental
improvements afterward or wait until it is more functional?
I would like to get it squeezed into this merge window unless there are
any objections and improve it afterwards.
* Huang Ying | 2009-06-18 10:08:27 [+0800]:
On Thu, 2009-06-18 at 04:04 +0800, Sebastian Andrzej Siewior wrote:
+#include linux/module.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/crypto.h
+#include crypto/gf128mul.h
+#include crypto/algapi.h
+#include crypto/internal
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
to:
|BUG: sleeping function called from invalid context at kernel/rwsem.c:21
|in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name: modprobe
|INFO: lockdep
* Neil Horman | 2009-06-30 20:06:48 [-0400]:
I think this looks better, yeah, have you tested this? If not, give it a quick
run please, and I'll ack it.
I've built it and started
| modprobe tcrypt mode=150
and I ended up with:
| alg: No test for stdrng (ansi_cprng)
So this should be fine I
* Sebastian Andrzej Siewior | 2009-07-02 08:02:55 [+0200]:
* Neil Horman | 2009-07-01 11:52:19 [-0400]:
index f9bea9d..3315a38 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1480,7 +1480,7 @@ static int alg_test_cprng(const struct alg_test_desc
*desc, const char *driver,
/* Please
* Herbert Xu | 2009-07-02 16:32:59 [+0800]:
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2365,14 +2366,22 @@ int alg_test(const char *driver, const char *alg, u32
type, u32 mask)
}
i = alg_find_test(alg);
- if (i 0)
+ j = alg_find_test(driver);
+ if (i 0 j
* Herbert Xu | 2009-07-11 18:19:58 [+0800]:
As I don't have the hardware supporting padlock-sha, could someone
with access to it please test this for me? In particular, I'd like
to see this tested with an actual IPsec connection.
I have here a via nano so I should be able to test it.
Do you have
* Herbert Xu | 2009-07-15 08:48:47 [+0800]:
Yes, that should be enough. You don't even ipsec-tools, just
a manual SA setup with ip xfrm should be good enough.
I did not get that far:
|alg: hash: Chunking test 1 failed for sha1-padlock
|: e9 95 22 0c 1b d1 0f 5f f1 fa ee 74 7d 27 cd b2
* Herbert Xu | 2009-07-16 10:34:13 [+0800]:
On Thu, Jul 16, 2009 at 10:16:01AM +0800, Herbert Xu wrote:
Can you please pull my tree again? There were quite a few bugs
that I fixed last night.
Oh and please make sure you have this patch applied too:
It passes the testmgr with that patch on
* Sebastian Andrzej Siewior | 2009-07-16 09:36:30 [+0200]:
* Herbert Xu | 2009-07-16 10:34:13 [+0800]:
On Thu, Jul 16, 2009 at 10:16:01AM +0800, Herbert Xu wrote:
Can you please pull my tree again? There were quite a few bugs
that I fixed last night.
Oh and please make sure you have
* Nico Erfurth | 2009-07-28 10:26:54 [+0200]:
Does anybody have an idea how I could get the crashdump so I can send it to
the list? If there is no other way I'll write it down next time.
If you have a serial port you could dump it there (console=ttyS0 in the
kernel command line).
Could you
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
This adds support for Marvell's Cryptographic Engines and Security
Accelerator (CESA) which can be found on a few SoC.
Tested with dm-crypt.
Acked-by: Nicolas Pitre n...@marvell.com
Signed-off-by: Sebastian Andrzej Siewior sebast
* Randy Dunlap | 2009-08-27 12:34:01 [-0700]:
On 27/08/2009 Randy Dunlap wrote:
On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:
I'm having a pretty bizarre problem with my kernel crypto
configuration. I need support for a bog standard LUKS (aes /
cbc-essiv:sha256) / cryptsetup
* Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]:
the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
even though it has cbc compiled as module as well. but if I recompile
the same kernel sources with Celejars kernel .config, the problem
occurs. thus it must
* Jonas Meurer | 2009-09-01 02:51:20 [+0200]:
as you already discovered, that's because the initramfs hook script for
cryptroot adds some crypto modules manually in debian. currently these
are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend
on.
You could add something like
* Neil Horman | 2009-09-12 12:44:11 [-0400]:
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d8a9255..6700248 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -399,6 +399,12 @@ module_param(debug, bool, 0644);
* storing entropy in an entropy pool.
*
* Neil Horman | 2009-09-14 12:30:43 [-0400]:
Ok, version 2 of the patch, taking comments into account
looks good.
Sebastian
--
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
elen...@planet.nl
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
* Frans Pop | 2009-09-16 16:01:34 [+0200]:
Maybe it's a result of enabling the new config option CRYPTO_DEV_MV_CESA?
please don't blame my shiny new driver :)
Catalin: bisect leads to 8b592783a. I've renamed
* ?? ??? | 2009-10-20 18:28:34 [+0400]:
Dear all, I have a couple of questions about crypto internals, please
help me to understand some concepts. My drivers implements
CRYPTO_ALG_TYPE_BLKCIPHER algorithm and has to perform encryption via
DMA transfers.
In the end you might prefer to use
* Sergey Mironov | 2009-11-10 17:00:31 [+0300]:
116 static int geode_setkey_cip(struct crypto_tfm *tfm, const u8 *key,
117 unsigned int len)
118 {
...
/** BUG? Should it be 'op-fallback.cip' instead of 'op-fallback.blk' ? **/
138 op-fallback.blk-base.crt_flags =
-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
I have the feeling that the driver will deadlock anyway. Got to check
this once I find the board..
---
drivers/crypto/geode-aes.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b
From 0a61b446585324a3041ef0a138515ef936a14eb7 Mon Sep 17 00:00:00 2001
From: Sergey Mironov ier...@gmail.com
Date: Thu, 12 Nov 2009 11:30:02 +0300
Subject: [PATCH] Fixed typo bugs in geod-aes.c
On a second look could you please add something like:
crypto/geode: access fallback.cip cipher
From 335b39e0c55a1dba13cda3e8222947f2cb4120ed Mon Sep 17 00:00:00 2001
From: Sergey Mironov ier...@gmail.com
Date: Thu, 12 Nov 2009 13:10:05 +0300
Subject: [PATCH 2/2] aes_s390: access fallback.cip cipher fallback mode
|The fallback code in cipher mode touch the union fallback.blk instead
|of
* Roel Kluin | 2009-12-07 14:28:23 [+0100]:
Return the PTR_ERR of the correct pointer.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/crypto/geode-aes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
* Herbert Xu | 2009-12-11 23:03:49 [+0800]:
On Mon, Dec 07, 2009 at 03:14:33PM +0100, Roel Kluin wrote:
Return the PTR_ERR of the correct pointer.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Patch applied. Thank you.
Martin picked an earlier version of this patch [0] which is allready
. This did not show any side effects yet because both types /
structs contain the same element right now.
[bige...@breakpoint: different commit message, split the patch in two and
rebase ]
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior
. This did not show any side effects yet because both types /
structs contain the same element right now.
[bige...@breakpoint: different commit message, split the patch in two]
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
* Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:
yes, I think it is better.
(...and I just forgot to add that test to dm-crypt after that suggestion.)
Milan
Hmm, there is salsa20 that has block size 1, larger initialization
vectors, and can be used to encrypt disks (although salsa20
* Bai Shuwei | 2010-01-28 17:12:46 [+0800]:
When I add the hardware device driver for crypto, i get the bellow
error information. My kernel is 2.6.26
[ 319.938922] Call Trace:
[ 319.938926] [80427cd4] schedule+0x95/0x635
[ 319.938934] [a0eb629b]
* Herbert Xu | 2010-02-09 18:37:18 [+1100]:
Mikulas Patocka mpato...@redhat.com wrote:
You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a
cipher can't be used to encrypt disks.
No, please see my reply in the previous thread. What we should
do is fix arc4. I just
* Herbert Xu | 2010-02-10 07:45:19 [+1100]:
Herbert, what happend to the check for streamcipher idea you had? Is
it gone? On the other hand it wouldn't be probably that bad to have a
Well again whether that should be done is up to the dm-crypt
maintainers.
Milan liked that afaik.
seprate
* richih.mailingl...@gmail.com | 2010-02-10 02:17:39 [+0100]:
From: Richard Hartmann richih.mailingl...@gmail.com
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
crypto/arc4.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
I've made this whitespace fixes
by the blkcipher itself,
I removed the select statement.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
I had it run with wireless and dm-crypt. No problems so far. Not sure if
it makes sense to rename it to arc4 and strip the ecb prefix. It would
make it consistent with salsa
* Adrian-Ken Rueegsegger | 2010-02-12 10:34:27 [+0100]:
Hi,
Hi,
Sebastian Andrzej Siewior schrieb:
The name is still ecb(aes) but since this is provided by the blkcipher
itself,
Just to avoid any confusion you meant ecb(arc4) not ecb(aes) here right?
Yes, I do. Not sure how I got aes
* Sebastian Andrzej Siewior | 2010-02-12 09:42:28 [+0100]:
+static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
{
- struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
+ if (unlikely(!ctx-new_key))
That should be likely(). Do you want me resend the whole thing? Haven't
noticed anything
* Herbert Xu | 2010-02-15 08:10:08 [+0800]:
How about we just remove it? It's not on a hot path anyway.
Sure.
I can do this when integrating the patch so you don't have to
resend.
Okay, thanks.
Thanks,
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the
* Wang, Shane | 2010-02-21 13:32:49 [+0800]:
--- a/crypto/vmac.cThu Feb 11 00:45:57 2010 -0800
+++ b/crypto/vmac.cSun Feb 21 02:23:01 2010 -0800
@@ -42,6 +42,8 @@ const u64 m63 = UINT64_C(0x7ff
const u64 m63 = UINT64_C(0x7fff); /* 63-bit mask */
const u64
* Herbert Xu | 2010-02-16 20:51:25 [+0800]:
On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
-static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
{
-struct arc4_ctx *ctx = crypto_tfm_ctx
* Herbert Xu | 2010-02-22 08:52:17 [+0800]:
On Mon, Feb 22, 2010 at 08:45:47AM +0800, Herbert Xu wrote:
How about this? You extend the IV by one more byte, and use that
byte as a boolean flag to indicate whether the IV is valid. All
So I trick the crypto api to allocate more bytes than
the same result for a given IV. If the IV is supplied as a plain
key then it wil be converted into a different internal state.
The name is now arc4.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
crypto/Kconfig |2 +-
crypto/arc4.c
The blk version of arc4 is comming. The rename ensures that the request
for arc4 loads both modules: this one and the new blk edition.
Cc: linux-...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
crypto/Makefile |2 +-
crypto/{arc4.c
This patch series converts arc4 into a block cipher and converts all its
users (except those in staging) to use it. The first two patches ensure
that two implementations can coexist, the following patches convert each
user so we remain bisectable.
- lib80211_crypt_tkip was tested with ipw2200
-
ecb(arc4) is getting replaced by arc4 which is a blkcipher by itself. The
required selects are now pulled in by LIB80211_CRYPT_WEP instead of
selecting it by every driver. Since there is no dependency on ecb and arc4
therr are removed from the idividual driver.
Signed-off-by: Sebastian Andrzej
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
crypto/testmgr.c | 60 +-
1 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 7620bfc..c471e04 100644
--- a/crypto
ecb(arc4) is getting replaced by arc4 which is a blkcipher by itself. The
required selects are now pulled in by LIB80211_CRYPT_TKIP instead of
selecting it by every driver.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
net/wireless/Kconfig |2 ++
net
ecb(arc4) is getting replaced by arc4 which is a blkcipher by itself
Cc: linux-...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/net/Kconfig|3 +--
drivers/net/ppp_mppe.c | 12 ++--
2 files changed, 7 insertions(+), 8 deletions
ecb(arc4) is getting replaced by arc4 which is a blkcipher by itself.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
net/mac80211/Kconfig |3 +--
net/mac80211/wep.c | 11 +++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/Kconfig
This is a pure blkcipher implementation of ARC4. The internal state is
saved within an IV which is supplied by the user. The goal is that the
cipher does not change its internal state now, only the iv changes during
encryption.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
* Herbert Xu | 2010-04-06 20:44:12 [+0800]:
On Mon, Apr 05, 2010 at 07:04:06PM +0200, Sebastian Andrzej Siewior wrote:
+static void arc4_key_to_iv(const u8 *in_key, u32 key_len, struct arc4_iv
*iv)
+{
+int i, j = 0, k = 0;
+
+iv-iv.x = 1;
+iv-iv.y = 0;
+
+for (i = 0; i
* Herbert Xu | 2010-04-07 08:31:09 [+0800]:
On Tue, Apr 06, 2010 at 10:30:02PM +0200, Sebastian Andrzej Siewior wrote:
Good point. All arc4 users don't care about return value of setkey so I
think that I just change void to int add the check for the valid key
length.
Actually, how about
* Pavel Roskin | 2010-04-07 02:19:55 [-0400]:
On Mon, 2010-04-05 at 19:04 +0200, Sebastian Andrzej Siewior wrote:
+module_init(arc4_init);
+module_exit(arc4_exit);
I'm feelings uneasy about using the same module init/exit functions
names in arc4blk.c and arc4cip.c.
Even though it doesn't
* Herbert Xu | 2010-04-07 17:29:07 [+0800]:
Sebastian, how about precomputing the IV and provide them directly
as a hex array?
To test arc4_setup_iv itself, you can add an alg_test_arc4 function
(like alg_test_crc32) that tests IV generation specifically.
Alternatively, just add an
* Chihau Chau | 2010-04-15 13:17:59 [-0400]:
From: Chihau Chau chi...@gmail.com
This fixes some code style issues like:
looks good
Sebastian
--
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
* Uri Simchoni | 2010-04-22 06:23:12 [+0300]:
I have some IPSec background but am not familiar with the Linux implementation
(I'm using the mv_cesa for SSL acceleration through a usermode interface I'm
working on). Can you point me to the nearest howto? I suppose I could have a
look.
If it is
* Sebastian Andrzej Siewior | 2010-04-24 17:12:07 [+0200]:
For IPSec I use this[0] shell script which sets up a connection. Good for
[0] http://breakpoint.cc/ipsec.sh
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord
* Herbert Xu | 2010-04-26 09:17:11 [+0800]:
OK that was my fault. Steffen had all the requisite EINPROGRESS
checks in place but I told him to get rid of them.
This patch should fix it.
Excellent job Herbert, it does solve the problem.
Sebastian
--
To unsubscribe from this list: send the line
* Manuel Lauss | 2010-05-05 14:02:15 [+0200]:
I've written a prototype driver for an AES accelerator; I'd like to test it
now. Are there any userspace tools available for this?
modprobe tcrypt mode=10
will test varios blockmodes. There is no userland interface for hw
driver atm.
Thanks!
* Manuel Lauss | 2010-05-06 17:50:45 [+0200]:
A brief look.
lightly tested with the tcrypt module on Au1200; I have no idea whether
it really works correctly:
# modprobe alchemy-aes
alg: skcipher: setkey failed on test 2 for ecb-aes-alchemy: flags=20
# modprobe tcrypt mode=10
alg: skcipher:
* Phil Sutter | 2010-06-10 20:22:29 [+0200]:
Hello everyone,
Hi Phil,
please take look at [0] and [1]. From README I can tell that those two
posts are different from you have so far.
You might want to take a look at AF_PACKET interface. It does zero copy
via a ring buffer interface of pre-mmaped
* Nikos Mavrogiannopoulos | 2010-06-11 09:47:15 [+0200]:
Sebastian Andrzej Siewior wrote:
* Phil Sutter | 2010-06-10 20:22:29 [+0200]:
The problem with right or wrong is that they are only known afterwards.
For me the right way to go is _to go_. I can see discussions in this
least, years ago
On Wed, Feb 22, 2012 at 09:10:46PM +0100, Nikos Mavrogiannopoulos wrote:
On 02/22/2012 02:03 PM, Frank wrote:
Hi,
After doing some trials with hardware crypto offloading through usermode
interfaces (af_alg and cryptodev) to Marvell CESA accelerated ciphers and
hash functions with
-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
On a side note: do we pull in the blkcipher block mode for each cipher now to
gain some extra performance like the openssl project? I was under the
impression that is in general not worth it.
crypto/Kconfig |2 +-
1 file changed, 1
Users of rwlocks should include spinlock.h instead including this
header file. The current users of rwlocks_types.h are internal.
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
---
drivers/crypto/ccp/ccp-dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/
ert <steffen.klass...@secunet.com>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
---
include/linux/padata.h | 2 +-
kernel/padata.c| 92 --
2 files changed, 53 insertions(+), 41 deletions
On 2017-06-19 22:55:37 [+0200], Jason A. Donenfeld wrote:
> On Mon, Jun 19, 2017 at 9:45 AM, Sebastian Andrzej Siewior
> <bige...@linutronix.de> wrote:
> > ehm. You sure? I simply delayed the lock-dropping _after_ the state
> > variable was been modified. So it was basic
On 2017-06-08 01:25:55 [+0200], Jason A. Donenfeld wrote:
> It's possible that get_random_{u32,u64} is used before the crng has
> initialized, in which case, its output might not be cryptographically
> secure. For this problem, directly, this patch set is introducing the
> *_wait variety of
On 2017-06-15 00:33:12 [+0200], Jason A. Donenfeld wrote:
> There's a potential race that I fixed in my v5 of that patch set, but
> Ted only took v4, and for whatever reason has been to busy to submit
> the additional patch I already posted showing the diff between v4
> Hopefully he actually gets
On 2017-06-15 00:45:26 [+0200], Jason A. Donenfeld wrote:
> Odd versions of gcc for the sh4 architecture will actually warn about
> flags being used while uninitialized, so we set them to zero. Non crazy
> gccs will optimize that out again, so it doesn't make a difference.
that is minor
> Next,
On 2017-06-16 14:12:42 [+0200], Jason A. Donenfeld wrote:
> I actually figured that out myself after sending the initial email, so
> then I wrote a follow-up patch which I attached to this thread. You
> should have received it. Can you take a look?
replied to the patch.
Sebastian
On 2017-06-17 02:39:40 [+0200], Jason A. Donenfeld wrote:
> On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior
> <bige...@linutronix.de> wrote:
> > I wouldn't just push the lock one up as is but move that write part to
> > crng_init to remain within the locked sec
RCE_RR_CPU=y.
Again, the preempt_disable() won't work here but lock which was
introduced will help.
In order to keep work-item on the local CPU (and avoid RR) I changed it
to queue_work_on().
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
---
| worker_thread+0x1d4/0x3a0
| kthread+0xfe/0x130
| ret_from_fork+0x27/0x50
If any locking is required, a simple mutex will do it.
Cc: Gary R Hook <gary.h...@amd.com>
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
---
drivers/crypto/ccp/ccp-debugfs.c | 7 +++
1 fil
On 2018-02-25 21:04:27 [-0500], Hook, Gary wrote:
> On 2/23/2018 5:33 PM, Sebastian Andrzej Siewior wrote:
> > I don't why we need take a single write lock and disable interrupts
> > while setting up debugfs. This is what what happens when we try anyway:
>
> There is more
On 2018-07-24 19:12:20 [+0200], Ard Biesheuvel wrote:
> Vakul reports a considerable performance hit when running the accelerated
> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
> been updated to take the TIF_NEED_RESCHED flag into account.
just in time. I will try to
On 2018-02-27 11:08:56 [-0600], Gary R Hook wrote:
> That issue remains unclear to me: Are probes of PCI devices guaranteed to be
> serialized? Observations on my CCPs says that they occur in order, but I
> don't know for certain that serialization is guaranteed.
>
> Is there a definitive
On 2018-02-27 19:40:34 [+0100], Greg Kroah-Hartman wrote:
> On Tue, Feb 27, 2018 at 06:33:14PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-02-27 11:08:56 [-0600], Gary R Hook wrote:
> > > That issue remains unclear to me: Are probes of PCI devices guaranteed to
> &g
100 matches
Mail list logo
