Hi Nicolas,
On Thu, Dec 10, 2020 at 02:18:45PM +0100, Nicolas Dichtel wrote:
> Le 10/12/2020 à 12:48, Eyal Birger a écrit :
> > On Thu, Dec 10, 2020 at 1:10 PM Nicolas Dichtel
> > wrote:
> [snip]
> > I also think they should be consistent. But it'd still be confusing to me
> > to get an OUTPUT ho
Hi Eyal,
On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote:
> On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter wrote:
> >
> > With an IPsec tunnel without dedicated interface, netfilter sees locally
> > generated packets twice as they exit the physical interface: O
Hi Nicolas,
On Tue, Dec 08, 2020 at 10:02:16AM +0100, Nicolas Dichtel wrote:
> Le 07/12/2020 à 14:43, Phil Sutter a écrit :
[...]
> > diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
> > index aa4cdcf69d471..24af61c95b4d4 100644
> > --- a/net/xfrm/xfrm_inte
again from netfilter's point of view.
Fixes: f203b76d78092 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Phil Sutter
---
Changes since v1:
- Extend recipients list, no code changes.
---
net/xfrm/xfrm_interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ne
again from netfilter's point of view.
Fixes: f203b76d78092 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Phil Sutter
---
net/xfrm/xfrm_interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index aa4
Hi Steffen,
On Wed, Dec 02, 2020 at 02:18:47PM +0100, Steffen Klassert wrote:
> On Fri, Nov 27, 2020 at 03:10:48PM +0100, Phil Sutter wrote:
[...]
> > diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
> > index aa4cdcf69d471..24af61c95b4d4 100644
>
On Fri, Nov 27, 2020 at 10:55:11AM +0100, Steffen Klassert wrote:
> On Thu, Nov 26, 2020 at 02:12:00PM +0100, Phil Sutter wrote:
> > > >
> > > > Is this a bug or an expected quirk when using XFRM interface?
> > >
> > > This is expected behavio
Hi Steffen,
On Thu, Nov 26, 2020 at 10:40:21AM +0100, Steffen Klassert wrote:
> On Wed, Nov 25, 2020 at 12:23:42PM +0100, Phil Sutter wrote:
> > I am working on a ticket complaining about netfilter policy match
> > missing packets in OUTPUT chain if XFRM interface is being used.
&
Hi Steffen,
I am working on a ticket complaining about netfilter policy match
missing packets in OUTPUT chain if XFRM interface is being used.
I don't fully overlook the relevant code path, but it seems like
skb_dest(skb)->xfrm is not yet assigned when the skb is routed towards
XFRM interface and
Hi,
On Tue, Nov 24, 2015 at 12:20:00PM +0100, Hannes Frederic Sowa wrote:
> Stephan Mueller writes:
>
> > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote:
> >>> Userspace crypto interface for TLS
On Mon, Jul 28, 2014 at 03:24:43PM +0200, Muran Hrun wrote:
> Hi,
>
> What is the status of DMA support for mv_cesa? I tried applying the patches at
> git://nwl.cc/~n0-1/linux.git (cesa-dma branch)
> on kernel 3.15.6 but the kernel just crashed on my DNS-320, when
> accessing an encrypted volume.
. This is because software SHA1 is used as fallback,
accessing the context's data which was layed out differently before this
patch.
I have not checked, but other crypto engine drivers might be affected by
that, as well.
> Acked-by: Ard Biesheuvel
> Signed-off-by: Jussi Kivilinna
A
Hey,
On Tue, Jul 31, 2012 at 08:12:02PM +0800, cloudy.linux wrote:
> Sorry for taking so long time to try the latest code. Just came back
> from a vacation and tried several days to get a tight sleep.
My apologies for having a ~3months lag. Somehow I have totally forgotten
about your mail in my
On Mon, Jul 16, 2012 at 04:03:44PM +0200, Andrew Lunn wrote:
> On Mon, Jul 16, 2012 at 03:52:16PM +0200, Phil Sutter wrote:
> > Hey Andrew,
> >
> > On Mon, Jul 16, 2012 at 11:32:25AM +0200, Andrew Lunn wrote:
> > > I've not been following this thread too clo
t
place?
Greetings, Phil
Phil Sutter
Software Engineer
--
VNet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Management Buy-Out at Viprinet - please read
http://www.viprinet.com/en/mbo
Management Buy-Out bei Viprinet - bitte lesen Sie
http://www.viprinet.com/de/mbo
Phone/Zentrale
r decoding window logic and interrupt case as well as
decoding window permission fix and changing from FETCH_ND to programming
the first DMA descriptor's values manually.
In the long term, I probably should try to get access to some
appropriate hardware myself. This is rather a quiz game th
git got a few updates, including the code described above.
Would be great if you could give it a try.
Greetings, Phil
Phil Sutter
Software Engineer
--
VNet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Management Buy-Out at Viprinet - please read
http://www.viprinet.
gine.
>
> I shifted the clock init code a bit and while doing so, fixed some error
> case handling for mv_dma and mv_cesa. See proposed patch in next mail.
I applied that to my public git, thanks a lot!
Greetings, Phil
Phil Sutter
Software Engineer
--
VNet Europe GmbH
Mainzer St
n there.
Anyway, thanks a lot for your help so far! I hope next try shows some
progress at least.
Greetings, Phil
Phil Sutter
Software Engineer
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Phone/Zentrale: +49-6721-49030-0
Direct line/Durchwahl: +49-6721-49030-13
Hi,
On Mon, Jun 25, 2012 at 10:25:01PM +0800, cloudy.linux wrote:
> On 2012-6-25 21:40, Phil Sutter wrote:
> > Hi,
> >
> > On Wed, Jun 20, 2012 at 05:41:31PM +0200, Phil Sutter wrote:
> >> PS: I am currently working at the address decoding problem, will get
> >
Hi,
On Wed, Jun 20, 2012 at 05:41:31PM +0200, Phil Sutter wrote:
> PS: I am currently working at the address decoding problem, will get
> back to in a few days when I have something to test. So stay tuned!
I have updated the cesa-dma branch at git://nwl.cc/~n0-1/linux.git with
code setti
ed again which in turn generates the interrupt to signal
the software. So no DMA interrupt needed, and no software interaction in
between data copying and crypto operation, of course. :)
Greetings, Phil
PS: I am currently working at the address decoding problem, will get
back to in a few days wh
Hi,
On Tue, Jun 19, 2012 at 11:09:43PM +0800, cloudy.linux wrote:
> On 2012-6-19 19:51, Phil Sutter wrote:
> > Hi Simon,
> >
> > On Mon, Jun 18, 2012 at 10:12:36PM +0200, Simon Baatz wrote:
> >> On Mon, Jun 18, 2012 at 03:47:18PM +0200, Phil Sutter wrote:
> >&
Hi Simon,
On Mon, Jun 18, 2012 at 10:12:36PM +0200, Simon Baatz wrote:
> On Mon, Jun 18, 2012 at 03:47:18PM +0200, Phil Sutter wrote:
> > On Sat, Jun 16, 2012 at 02:20:19AM +0200, Simon Baatz wrote:
> > > thanks for providing these patches; it's great to finally see DMA
&g
any equivalent place in the correspondent subdirectory. So I hope it is
OK like this.
The updated patch series is available at git://nwl.cc/~n0-1/linux.git,
branch 'cesa-dma'. My push changed history, so you have to either reset
--hard to it's HEAD, or rebase skipping the outdated p
ones of the earlier four. Yay.
Long story short, please just fetch git://nwl.cc/~n0-1/linux.git and
checkout the 'cesa-dma' branch. It's exactly what I formatted the
patches from.
Greetings, Phil
Phil Sutter
Software Engineer
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhe
The big problem is they cannot be used to iterate over DMA mapped
scatterlists, so get rid of them in order to add DMA functionality to
mv_cesa.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 57 ++---
1 files changed, 28 insertions(+), 29
These are DMA engines integrated into the Marvell Orion/Kirkwood SoCs,
designed to offload data transfers from/to the CESA crypto engine.
Signed-off-by: Phil Sutter
---
arch/arm/mach-kirkwood/common.c | 33 ++
arch/arm/mach-kirkwood/include/mach/irqs.h |1 +
arch/arm/mach
This is just to keep formatting changes out of the following commit,
hopefully simplifying it a bit.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
Hi,
The following patch series adds support for the TDMA engine built into
Marvell's Kirkwood-based SoCs as well as the IDMA engine built into
Marvell's Orion-based SoCs and enhances mv_cesa.c in order to use it for
speeding up crypto operations. The hardware contains a security
accelerator, which
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 89 ++
1 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 9c65980..86b73d1 100644
--- a/drivers/crypto/mv_cesa.c
+++ b
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 4b08137..7dfab85 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -158,6
This way reconfiguring the cryptographic accelerator consists of a
single step (memcpy here), which in future can be done by the tdma
engine.
This patch introduces some ugly IV copying, necessary for input buffers
above 1920bytes. But this will go away later.
Signed-off-by: Phil Sutter
Signed-off-by: Phil Sutter
---
arch/arm/plat-orion/common.c |6 +
drivers/crypto/mv_cesa.c | 214 +-
2 files changed, 175 insertions(+), 45 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 61fd837
Have a dedicated function initialising the full SRAM config, then use a
minimal callback for changing only relevant parts of it.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 87 +
1 files changed, 64 insertions(+), 23 deletions(-)
diff
Signed-off-by: Phil Sutter
---
drivers/crypto/dma_desclist.h | 79 +++
drivers/crypto/mv_cesa.c | 81 +
drivers/crypto/mv_dma.c | 91 -
3 files changed, 125 insertions
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 40 +---
1 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index cdbc82e..4b08137 100644
--- a/drivers/crypto/mv_cesa.c
+++ b
This introduces a pool of four-byte DMA buffers for security
accelerator config updates.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 134 --
drivers/crypto/mv_cesa.h |1 +
2 files changed, 106 insertions(+), 29 deletions(-)
diff
Check and exit early for whether CESA can be used at all.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 61 +-
1 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index
And while here, simplify dequeue_complete_req() a bit.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 86b73d1..7b2b693 100644
--- a
On Tue, Jun 12, 2012 at 06:04:37PM +0800, Herbert Xu wrote:
> On Fri, May 25, 2012 at 06:08:26PM +0200, Phil Sutter wrote:
> >
> > The point for this being RFC is backwards-compatibility: earlier
> > hardware (Orion) ships a (slightly) different DMA engine (IDMA) along
>
the hmac_comp tool, right? Did you hexdump and compare the
results already? Does encryption/hashing of blocks > 1920bytes fail
every time, also on first try (call 'hmac_comp 1920')?
Greetings, Phil
Phil Sutter
Software Engineer
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am R
Hi,
On Mon, May 28, 2012 at 09:58:32AM +0800, cloudy.linux wrote:
> On 2012-5-25 21:54, Phil Sutter wrote:
> > Also drop the whole definition, since it's unused otherwise.
> >
> > Signed-off-by: Phil Sutter
> > ---
> > drivers/crypto/mv_cesa.c |1 -
will be no fun at least.
Greetings, Phil
Phil Sutter
Software Engineer
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Phone/Zentrale: +49-6721-49030-0
Direct line/Durchwahl: +49-6721-49030-134
Fax:+49-6721-49030-209
phil.sut...@viprinet.com
http://ww
The big problem is they cannot be used to iterate over DMA mapped
scatterlists, so get rid of them in order to add DMA functionality to
mv_cesa.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 57 ++---
1 files changed, 28 insertions(+), 29
Hi,
The following patch series adds support for the TDMA engine built into
Marvell's Kirkwood-based SoCs, and enhances mv_cesa.c in order to use it
for speeding up crypto operations. Kirkwood hardware contains a security
accelerator, which can control DMA as well as crypto engines. It allows
for o
This way reconfiguring the cryptographic accelerator consists of a
single step (memcpy here), which in future can be done by the tdma
engine.
This patch introduces some ugly IV copying, necessary for input buffers
above 1920bytes. But this will go away later.
Signed-off-by: Phil Sutter
This introduces a pool of four-byte DMA buffers for security
accelerator config updates.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 134 --
drivers/crypto/mv_cesa.h |1 +
2 files changed, 106 insertions(+), 29 deletions(-)
diff
And while here, simplify dequeue_complete_req() a bit.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 9afed2d..9a2f413 100644
--- a
This is just to keep formatting changes out of the following commit,
hopefully simplifying it a bit.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
This is a DMA engine integrated into the Marvell Kirkwood SoC, designed
to offload data transfers from/to the CESA crypto engine.
Signed-off-by: Phil Sutter
---
arch/arm/mach-kirkwood/common.c| 33 +++
arch/arm/mach-kirkwood/include/mach/irqs.h |1 +
drivers/crypto/Kconfig
Simply chose the same DMA mask value as for mvsdio and ehci.
Signed-off-by: Phil Sutter
---
arch/arm/plat-orion/common.c |6 +
drivers/crypto/mv_cesa.c | 214 +-
2 files changed, 175 insertions(+), 45 deletions(-)
diff --git a/arch/arm/plat
Check and exit early for whether CESA can be used at all.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 61 +-
1 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 40 +---
1 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index e10da2b..d099aa0 100644
--- a/drivers/crypto/mv_cesa.c
+++ b
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index d099aa0..bc2692e 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -156,6
Signed-off-by: Phil Sutter
---
drivers/crypto/dma_desclist.h | 79 +++
drivers/crypto/mv_cesa.c | 81 +
drivers/crypto/mv_tdma.c | 91 -
3 files changed, 125 insertions
Have a dedicated function initialising the full SRAM config, then use a
minimal callback for changing only relevant parts of it.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 87 +
1 files changed, 64 insertions(+), 23 deletions(-)
diff
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 89 ++
1 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 5dba9df..9afed2d 100644
--- a/drivers/crypto/mv_cesa.c
+++ b
Since mv_hash_final_fallback() uses ctx->state, read out the digest
state register before calling it.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/cry
The timer triggers when 500ms have gone by after triggering the engine
and no completion interrupt was received. The callback then tries to
sanitise things as well as possible.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 41 +++--
1 files
Also drop the whole definition, since it's unused otherwise.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |1 -
drivers/crypto/mv_cesa.h |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 4a1f872..d4763fb 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1073,6 +1073,7
Hi,
On Sun, May 06, 2012 at 01:25:06PM +0100, Russell King - ARM Linux wrote:
> On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote:
> > since there has been no reaction on this, I would like to bring this
> > issue up again (I sadly don't have the expertise to investigate this
> > further
llow to
> verify:\n");
> printf("\n\topenssl enc -in UNENCRYPTED_FILE -iv 0 -K 0
> \\\n");
> printf("\t\t-out OPENSSL_ENCRYPTED_FILE -nopad
> -aes-128-cbc\n");
> return 1;
> }
>
> in
Broken by commit 6ef84509f3d439ed2d43ea40080643efec37f54f for users
passing a request with non-zero 'nbytes' field, like e.g. testmgr.
Cc: # 3.0+
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/driv
Hello,
On Wed, Feb 22, 2012 at 02:03:38PM +0100, Frank wrote:
> After doing some trials with hardware crypto offloading through usermode
> interfaces (af_alg and cryptodev) to Marvell CESA accelerated ciphers and
> hash functions with the 3.2.4 kernel's mv_cesa in Debian Wheezy on a Marvell
> K
This was broken by commit 7759995c75ae0cbd4c861582908449f6b6208e7a (yes,
myself). The basic problem here is since the digest state is only saved
after the last chunk, the state array is only valid when handling the
first chunk of the next buffer. Broken since linux-3.0.
Signed-off-by: Phil Sutter
Herbert,
On Thu, Sep 01, 2011 at 10:14:45PM +0800, Herbert Xu wrote:
> Phil Sutter wrote:
> >
> > chunksize af_alg cryptodev (100 * cryptodev / af_alg)
> > --
> > 512
Herbert,
On Thu, Sep 01, 2011 at 12:15:34PM +1000, Herbert Xu wrote:
> Nikos Mavrogiannopoulos wrote:
> >
> > Given my benchmarks have no issues, it is not apparent to me why one
> > should use AF_ALG instead of cryptodev. I do not know though why AF_ALG
> > performs so poor. I'd speculate by bla
Hi,
On Sun, Aug 28, 2011 at 03:17:00PM +0200, Nikos Mavrogiannopoulos wrote:
> I've compared the cryptodev [0] and AF_ALG interfaces in terms of
> performance [1]. I've put the results, as well as the benchmarks used
> in: http://home.gna.org/cryptodev-linux/comparison.html
Well done, Nikos!
I
The main goal was to have it not do anything when a zero len parameter
was being passed (which could lead to a null pointer dereference, as in
this case p->src_sg is null, either). Using the min() macro, the lower
part of the loop gets simpler, too.
Signed-off-by: Phil Sutter
---
drivers/cry
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 4aac294..c018cd0 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1061,12
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index de09303..c1925c2 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -296,6 +296,7
On one hand, the digest state registers need to be set only when
actually using the crypto engine. On the other hand, there is a check
for ctx->first_hash in mv_process_hash_current() already, so use that.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 14 ++
1 fi
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index c443246..889c098 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -275,7 +275,6
This also makes the dummy scatterlist in mv_hash_final() needless, so
drop it.
XXX: should this routine be made pulicly available? There are probably
other users with their own implementations.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |8 ++--
1 files changed, 2
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index c99305a..c443246 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -603,9 +603,7
The code in mv_hash_final is actually a superset of mv_hash_finup's
body. Since the driver works fine without, drop it.
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/c
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index c018cd0..fb3f1e3 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -407,12
Signed-off-by: Phil Sutter
---
drivers/crypto/mv_cesa.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a2d9e39..d704ed0 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -525,12
Hi,
On Mon, Apr 04, 2011 at 08:35:43PM -0500, Kim Phillips wrote:
> On Mon, 4 Apr 2011 19:03:37 +0200
> Phil Sutter wrote:
>
> > I would like to enhance drivers/crypto/mv_cesa.c by an AEAD algorithm
> > (at least authenc(hmac(sha1),cbc(aes))), since the driver is able to d
Dear list,
I would like to enhance drivers/crypto/mv_cesa.c by an AEAD algorithm
(at least authenc(hmac(sha1),cbc(aes))), since the driver is able to do
both operations in one go.
Unfortunately, I have found little information about this task in
Documentation/ or the web. Am I missing something?
Dear list,
I am doing performance tests on an Intel I5 (661 i think) based machine.
Thanks to the AES-NI extensions, I am able to get a throughput of about
500MB/s when doing AES256.
But for TLS, hashing performance is important, too. SSE4.2 provides no
equivalent extension for SHA-1, so that nee
Hi,
On Tue, Dec 07, 2010 at 07:39:56PM +0800, Herbert Xu wrote:
> On Tue, Dec 07, 2010 at 11:41:41AM +0100, Phil Sutter wrote:
> >
> > Yes, CONFIG_PREEMPT is active in my test system's kernel.
>
> OK, can you see if the problem is still reproducible without
> pr
Hi,
On Thu, Dec 02, 2010 at 02:14:41PM +0800, Herbert Xu wrote:
> > Yes, it does, but triggering the bug is not really trivial. I've had
> > best results with a speed testing tool using the asynchronous interface,
> > memory corruption occured in each run. The same tool operating
> > synchronously
Herbert,
On Thu, Nov 04, 2010 at 01:46:06PM -0500, Herbert Xu wrote:
> > On one hand, the original code is broken in padlock_xcrypt_cbc(): when
> > passing the "initial" bytes to xcryptcbc, 'count' is incorrectly used as
> > length. This may trigger prefetch-related issues, but will definitely
> >
tch fixes them:
Instead of handling the "odd" bytes (i.e., the remainder when dividing
into prefetch blocks of 64bytes) at the beginning, go for them in the
end, copying the data out if prefetching would run beyond the page
boundary.
Signed-off-by: Phil Sutter
Signed-off-by:
Hey Bigeasy,
On Thu, Jun 10, 2010 at 11:14:33PM +0200, Sebastian Andrzej Siewior wrote:
> please take look at [0] and [1]. From README I can tell that those two
> posts are different from you have so far.
Hmm. Indeed, using something like AF_CRYPTO didn't come to my mind so
far. Though I'm not su
Hey Bigeasy,
On Thu, Jun 10, 2010 at 11:14:33PM +0200, Sebastian Andrzej Siewior wrote:
> please take look at [0] and [1]. From README I can tell that those two
> posts are different from you have so far.
Hmm. Indeed, using something like AF_CRYPTO didn't come to my mind so
far. Though I'm not su
Hey,
Seems like I'm stabbing into open wounds. :) First of all, thanks a lot
for your comments.
On Fri, Jun 11, 2010 at 11:08:56AM +0200, Sebastian Andrzej Siewior wrote:
> * Nikos Mavrogiannopoulos | 2010-06-11 09:47:15 [+0200]:
>
> >Sebastian Andrzej Siewior wrote:
> >
Hello everyone,
my employer wants to have a lightweight, zero-copy user space interface
to the Crypto-API and I *think* I'm on the right way to realising this.
What I've got so far is just a proof-of-concept, tested only with
cbc(aes), merely as generic as I'd like it to be, but with zero-copy of
91 matches
Mail list logo
