Re: [PATCH 0/4] crypto/arm64: reduce impact of NEON yield checks

[Sebastian Andrzej Siewior]

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 come up with some numbers on RT with the
original patch and with that one. I have it almost working…

Sebastian

Re: Can a driver->probe be called for two devices at the same time (WAS: Re: [PATCH] crypto/ccp: don't disable interrupts while setting up debugfs)

[Sebastian Andrzej Siewior]

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 
> > > 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 statement on this somewhere that I just don't know
> > > about?
> 
> The bus enforces this.
> 
> > So the question if a driver can probe two devices simultaneously.
> 
> Depends on the bus type.

PCI

> thanks,
> 
> greg k-h

Sebastian

Can a driver->probe be called for two devices at the same time (WAS: Re: [PATCH] crypto/ccp: don't disable interrupts while setting up debugfs)

[Sebastian Andrzej Siewior]

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 statement on this somewhere that I just don't know
> about?

So the question if a driver can probe two devices simultaneously. I'm
not sure. We have PROBE_PREFER_ASYNCHRONOUS which defers the probe to
worker. However I have no idea if two of those worker can run at the
same time.

> I think a mutex would be just fine; I got this wrong, clearly. Let me work
> up a patch using a mutex.

I've sent one. Why not just ack it and be done with it?

> Gary

Sebastian

Re: [PATCH] crypto/ccp: don't disable interrupts while setting up debugfs

[Sebastian Andrzej Siewior]

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 than one CCP on some processors. The lock is intended to
> serialize attempts to initialize the new directory, but a R/W lock isn't
> required.

And they are probed in parallel? Any you need disable interrupts while
creating the debugfs folder? A mutex isn't enough?

> My testing on  an EPYC (8 CCPs) didn't expose this problem. May I ask what
> hardware you used here?
an EPYC, too. I have no idea how many CCPs were around but lspci -k
printed that driver more than once. Try to enable lockdep and "sleeping
while atomic".
But I did provide you a complete backtrace, look:

> > |ccp :03:00.2: enabling device ( -> 0002)
> > |BUG: sleeping function called from invalid context at 
> > kernel/locking/rwsem.c:69
> > |in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0
> > |irq event stamp: 17150
> > |hardirqs last  enabled at (17149): [<97a18c49>] 
> > restore_regs_and_return_to_kernel+0x0/0x23
> > |hardirqs last disabled at (17150): [<0773b3a9>] 
> > _raw_write_lock_irqsave+0x1b/0x50
> > |softirqs last  enabled at (17148): [<64d56155>] 
> > __do_softirq+0x3b8/0x4c1
> > |softirqs last disabled at (17125): [<92633c18>] irq_exit+0xb1/0xc0
> > |CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30
> > |Workqueue: events work_for_cpu_fn
> > |Call Trace:
> > | dump_stack+0x7d/0xb6
> > | ___might_sleep+0x1eb/0x250
> > | down_write+0x17/0x60
> > | start_creating+0x4c/0xe0
> > | debugfs_create_dir+0x9/0x100
> > | ccp5_debugfs_setup+0x191/0x1b0
> > | ccp5_init+0x8a7/0x8c0
> > | ccp_dev_init+0xb8/0xe0
> > | sp_init+0x6c/0x90
> > | sp_pci_probe+0x26e/0x590
> > | local_pci_probe+0x3f/0x90
> > | work_for_cpu_fn+0x11/0x20
> > | process_one_work+0x1ff/0x650
> > | worker_thread+0x1d4/0x3a0
> > | kthread+0xfe/0x130
> > | ret_from_fork+0x27/0x50

Sebastian

[PATCH] crypto/ccp: don't disable interrupts while setting up debugfs

[Sebastian Andrzej Siewior]

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:

|ccp :03:00.2: enabling device ( -> 0002)
|BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:69
|in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0
|irq event stamp: 17150
|hardirqs last  enabled at (17149): [<97a18c49>] 
restore_regs_and_return_to_kernel+0x0/0x23
|hardirqs last disabled at (17150): [<0773b3a9>] 
_raw_write_lock_irqsave+0x1b/0x50
|softirqs last  enabled at (17148): [<64d56155>] 
__do_softirq+0x3b8/0x4c1
|softirqs last disabled at (17125): [<92633c18>] irq_exit+0xb1/0xc0
|CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30
|Workqueue: events work_for_cpu_fn
|Call Trace:
| dump_stack+0x7d/0xb6
| ___might_sleep+0x1eb/0x250
| down_write+0x17/0x60
| start_creating+0x4c/0xe0
| debugfs_create_dir+0x9/0x100
| ccp5_debugfs_setup+0x191/0x1b0
| ccp5_init+0x8a7/0x8c0
| ccp_dev_init+0xb8/0xe0
| sp_init+0x6c/0x90
| sp_pci_probe+0x26e/0x590
| local_pci_probe+0x3f/0x90
| work_for_cpu_fn+0x11/0x20
| process_one_work+0x1ff/0x650
| 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 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs.c
index 59d4ca4e72d8..1a734bd2070a 100644
--- a/drivers/crypto/ccp/ccp-debugfs.c
+++ b/drivers/crypto/ccp/ccp-debugfs.c
@@ -278,7 +278,7 @@ static const struct file_operations ccp_debugfs_stats_ops = 
{
 };
 
 static struct dentry *ccp_debugfs_dir;
-static DEFINE_RWLOCK(ccp_debugfs_lock);
+static DEFINE_MUTEX(ccp_debugfs_lock);
 
 #defineMAX_NAME_LEN20
 
@@ -290,16 +290,15 @@ void ccp5_debugfs_setup(struct ccp_device *ccp)
struct dentry *debugfs_stats;
struct dentry *debugfs_q_instance;
struct dentry *debugfs_q_stats;
-   unsigned long flags;
int i;
 
if (!debugfs_initialized())
return;
 
-   write_lock_irqsave(_debugfs_lock, flags);
+   mutex_lock(_debugfs_lock);
if (!ccp_debugfs_dir)
ccp_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
-   write_unlock_irqrestore(_debugfs_lock, flags);
+   mutex_unlock(_debugfs_lock);
if (!ccp_debugfs_dir)
return;
 
-- 
2.16.1

[PATCH] crypto: mcryptd: protect the per-CPU queue with a lock

[Sebastian Andrzej Siewior]

mcryptd_enqueue_request() grabs the per-CPU queue struct and protects
access to it with disabled preemption. Then it schedules a worker on the
same CPU. The worker in mcryptd_queue_worker() guards access to the same
per-CPU variable with disabled preemption.

If we take CPU-hotplug into account then it is possible that between
queue_work_on() and the actual invocation of the worker the CPU goes
down and the worker will be scheduled on _another_ CPU. And here the
preempt_disable() protection does not work anymore. The easiest thing is
to add a spin_lock() to guard access to the list.

Another detail: mcryptd_queue_worker() is not processing more than
MCRYPTD_BATCH invocation in a row. If there are still items left, then
it will invoke queue_work() to proceed with more later. *I* would
suggest to simply drop that check because it does not use a system
workqueue and the workqueue is already marked as "CPU_INTENSIVE". And if
preemption is required then the scheduler should do it.
However if queue_work() is used then the work item is marked as CPU
unbound. That means it will try to run on the local CPU but it may run
on another CPU as well. Especially with CONFIG_DEBUG_WQ_FORCE_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>
---
 crypto/mcryptd.c | 23 ++-
 include/crypto/mcryptd.h |  1 +
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index 4e6472658852..eca04d3729b3 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -81,6 +81,7 @@ static int mcryptd_init_queue(struct mcryptd_queue *queue,
pr_debug("cpu_queue #%d %p\n", cpu, queue->cpu_queue);
crypto_init_queue(_queue->queue, max_cpu_qlen);
INIT_WORK(_queue->work, mcryptd_queue_worker);
+   spin_lock_init(_queue->q_lock);
}
return 0;
 }
@@ -104,15 +105,16 @@ static int mcryptd_enqueue_request(struct mcryptd_queue 
*queue,
int cpu, err;
struct mcryptd_cpu_queue *cpu_queue;
 
-   cpu = get_cpu();
-   cpu_queue = this_cpu_ptr(queue->cpu_queue);
-   rctx->tag.cpu = cpu;
+   cpu_queue = raw_cpu_ptr(queue->cpu_queue);
+   spin_lock(_queue->q_lock);
+   cpu = smp_processor_id();
+   rctx->tag.cpu = smp_processor_id();
 
err = crypto_enqueue_request(_queue->queue, request);
pr_debug("enqueue request: cpu %d cpu_queue %p request %p\n",
 cpu, cpu_queue, request);
+   spin_unlock(_queue->q_lock);
queue_work_on(cpu, kcrypto_wq, _queue->work);
-   put_cpu();
 
return err;
 }
@@ -161,16 +163,11 @@ static void mcryptd_queue_worker(struct work_struct *work)
cpu_queue = container_of(work, struct mcryptd_cpu_queue, work);
i = 0;
while (i < MCRYPTD_BATCH || single_task_running()) {
-   /*
-* preempt_disable/enable is used to prevent
-* being preempted by mcryptd_enqueue_request()
-*/
-   local_bh_disable();
-   preempt_disable();
+
+   spin_lock_bh(_queue->q_lock);
backlog = crypto_get_backlog(_queue->queue);
req = crypto_dequeue_request(_queue->queue);
-   preempt_enable();
-   local_bh_enable();
+   spin_unlock_bh(_queue->q_lock);
 
if (!req) {
mcryptd_opportunistic_flush();
@@ -185,7 +182,7 @@ static void mcryptd_queue_worker(struct work_struct *work)
++i;
}
if (cpu_queue->queue.qlen)
-   queue_work(kcrypto_wq, _queue->work);
+   queue_work_on(smp_processor_id(), kcrypto_wq, _queue->work);
 }
 
 void mcryptd_flusher(struct work_struct *__work)
diff --git a/include/crypto/mcryptd.h b/include/crypto/mcryptd.h
index cceafa01f907..b67404fc4b34 100644
--- a/include/crypto/mcryptd.h
+++ b/include/crypto/mcryptd.h
@@ -27,6 +27,7 @@ static inline struct mcryptd_ahash *__mcryptd_ahash_cast(
 
 struct mcryptd_cpu_queue {
struct crypto_queue queue;
+   spinlock_t q_lock;
struct work_struct work;
 };
 
-- 
2.15.0

Re: [PATCH] random: silence compiler warnings and fix race

[Sebastian Andrzej Siewior]

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 basically what your patch did
> > except it was unlocked later…
> 
> Yes, I'm sure. You moved the call to invalidate_batched_entropy() to
> be after the assignment of crng_init. However, the call to
> invalidate_batched_entropy() must be made _before_ the assignment of
> crng_init.

so you need to find a another way then. Doing the assignment after
dropping the lock opens another race.

> >> > Are use about that? I am not sure that the gcc will inline "crng_init"
> >> > read twice. It is not a local variable. READ_ONCE() is usually used
> >> > where gcc could cache a memory access but you do not want this. But hey!
> >> > If someone knows better I am here to learn.
> >>
> >> The whole purpose is that I _want_ it to cache the memory access so
> >> that it is _not_ inlined. So, based on your understanding, it does
> >> exactly what I intended it to do. The reason is that I'd like to avoid
> >> a lock imbalance, which could happen if the read is inlined.
> >
> > So it was good as it was which means you can drop that READ_ONCE().
> 
> Except READ_ONCE ensures that the compiler will never inline it, so it
> actually needs to stay.

I don't think the compiler is allowed to inline it the way you describe
it. This would render any assignment to local variable useless. Also
the READ_ONCE creates worse code in this case (because the read can not
be delayed).

Sebastian

Re: [PATCH] random: silence compiler warnings and fix race

[Sebastian Andrzej Siewior]

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 section. Like that:
> 
> We can't quite do that, because invalidate_batched_entropy() needs to
> be called _before_ crng_init. Otherwise a concurrent call to
> get_random_u32/u64() will have crng_init being the wrong value when
> the batched entropy is still old.

ehm. You sure? I simply delayed the lock-dropping _after_ the state
variable was been modified. So it was basically what your patch did
except it was unlocked later…

> 
> > Are use about that? I am not sure that the gcc will inline "crng_init"
> > read twice. It is not a local variable. READ_ONCE() is usually used
> > where gcc could cache a memory access but you do not want this. But hey!
> > If someone knows better I am here to learn.
> 
> The whole purpose is that I _want_ it to cache the memory access so
> that it is _not_ inlined. So, based on your understanding, it does
> exactly what I intended it to do. The reason is that I'd like to avoid
> a lock imbalance, which could happen if the read is inlined.

So it was good as it was which means you can drop that READ_ONCE().

> Jason

Sebastian

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

[Sebastian Andrzej Siewior]

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

Re: [PATCH] random: silence compiler warnings and fix race

[Sebastian Andrzej Siewior]

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, over aggressive gccs could inline the expression that defines
> use_lock, which could then introduce a race resulting in a lock
> imbalance. By using READ_ONCE, we prevent that fate. Finally, we make
> that assignment const, so that gcc can still optimize a nice amount.

Not sure about that, more below.

> Finally, we fix a potential deadlock between primary_crng.lock and
> batched_entropy_reset_lock, where they could be called in opposite
> order. Moving the call to invalidate_batched_entropy to outside the lock
> rectifies this issue.

and *that* is separate issue which has to pulled in for stable once it
has been addressed in Linus' tree.

> Signed-off-by: Jason A. Donenfeld 
> ---
> Ted -- the first part of this is the fixup patch we discussed earlier.
> Then I added on top a fix for a potentially related race.
> 
> I'm not totally convinced that moving this block to outside the spinlock
> is 100% okay, so please give this a close look before merging.
> 
> 
>  drivers/char/random.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e870f329db88..01a260f67437 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -803,13 +803,13 @@ static int crng_fast_load(const char *cp, size_t len)
>   p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
>   cp++; crng_init_cnt++; len--;
>   }
> + spin_unlock_irqrestore(_crng.lock, flags);
>   if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
>   invalidate_batched_entropy();
>   crng_init = 1;
>   wake_up_interruptible(_init_wait);
>   pr_notice("random: fast init done\n");
>   }
> - spin_unlock_irqrestore(_crng.lock, flags);
>   return 1;

I wouldn't just push the lock one up as is but move that write part to
crng_init to remain within the locked section. Like that:

diff --git a/drivers/char/random.c b/drivers/char/random.c
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -804,12 +804,14 @@ static int crng_fast_load(const char *cp, size_t len)
cp++; crng_init_cnt++; len--;
}
if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
-   invalidate_batched_entropy();
crng_init = 1;
+   spin_unlock_irqrestore(_crng.lock, flags);
+   invalidate_batched_entropy();
wake_up_interruptible(_init_wait);
pr_notice("random: fast init done\n");
+   } else {
+   spin_unlock_irqrestore(_crng.lock, flags);
}
-   spin_unlock_irqrestore(_crng.lock, flags);
return 1;
 }
 
@@ -842,13 +844,16 @@ static void crng_reseed(struct crng_state *crng, struct 
entropy_store *r)
memzero_explicit(, sizeof(buf));
crng->init_time = jiffies;
if (crng == _crng && crng_init < 2) {
-   invalidate_batched_entropy();
crng_init = 2;
+   spin_unlock_irqrestore(_crng.lock, flags);
+
+   invalidate_batched_entropy();
process_random_ready_list();
wake_up_interruptible(_init_wait);
pr_notice("random: crng init done\n");
+   } else {
+   spin_unlock_irqrestore(_crng.lock, flags);
}
-   spin_unlock_irqrestore(_crng.lock, flags);
 }
 
 static inline void crng_wait_ready(void)

>  }
>  
> @@ -2041,8 +2041,8 @@ static DEFINE_PER_CPU(struct batched_entropy, 
> batched_entropy_u64);
>  u64 get_random_u64(void)
>  {
>   u64 ret;
> - bool use_lock = crng_init < 2;
> - unsigned long flags;
> + bool use_lock = READ_ONCE(crng_init) < 2;

Are use about that? I am not sure that the gcc will inline "crng_init"
read twice. It is not a local variable. READ_ONCE() is usually used
where gcc could cache a memory access but you do not want this. But hey!
If someone knows better I am here to learn.
One thing that this change does for sure is that crng_init is read very
early in the function while without READ_ONCE it is delayed _after_
arch_get_random_XXX(). So if arch_get_random_XXX() is around and works
you have one read for nothing.

> + unsigned long flags = 0;
>   struct batched_entropy *batch;
>  
>  #if BITS_PER_LONG == 64

Sebastian

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

[Sebastian Andrzej Siewior]

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 around to it and sends this for the next
> rc. Here it is:
> 
> https://patchwork.kernel.org/patch/9774563/

So you replace "crng_init < 2" with use_lock instead. That is not what I
am talking about. Again:
add_interrupt_randomness()
->   crng_fast_load()   
spin_trylock_irqsave(_crng.lock, )
->invalidate_batched_entropy()  
write_lock_irqsave(_entropy_reset_lock, );

in that order while the code path
get_random_uXX()
read_lock_irqsave(_entropy_reset_lock, );
->   extract_crng()
->_extract_crng()spin_lock_irqsave(>lock, );

which allocates the same lock in opposite order.
That means
  T1T2
  crng_fast_load()  get_random_u64()
extract_crng()
  *dead lock*
invalidate_batched_entropy()
_extract_crng()

So T1 waits for batched_entropy_reset_lock holding primary_crng.lock and
T2 waits for primary_crng.lock holding batched_entropy_reset_lock.

Sebastian

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

[Sebastian Andrzej Siewior]

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 functions, but even with that, there's a subtle issue:
> what happens to our batched entropy that was generated before
> initialization. Prior to this commit, it'd stick around, supplying bad
> numbers. After this commit, we force the entropy to be re-extracted
> after each phase of the crng has initialized.
> 
> In order to avoid a race condition with the position counter, we
> introduce a simple rwlock for this invalidation. Since it's only during
> this awkward transition period, after things are all set up, we stop
> using it, so that it doesn't have an impact on performance.
> 
> This should probably be backported to 4.11.
> 
> (Also: adding my copyright to the top. With the patch series from
> January, this patch, and then the ones that come after, I think there's
> a relevant amount of code in here to add my name to the top.)
> 
> Signed-off-by: Jason A. Donenfeld 
> Cc: Greg Kroah-Hartman 

I don't understand why lockdep notices this possible deadlock only in
RT:

| the existing dependency chain (in reverse order) is:
|
| -> #1 (primary_crng.lock){+.+...}:
|lock_acquire+0xb5/0x2b0
|rt_spin_lock+0x46/0x50
|_extract_crng+0x39/0xa0
|extract_crng+0x3a/0x40
|get_random_u64+0x17a/0x200
|cache_random_seq_create+0x51/0x100
|init_cache_random_seq+0x35/0x90
|__kmem_cache_create+0xd3/0x560
|create_boot_cache+0x8c/0xb2
|create_kmalloc_cache+0x54/0x9f
|create_kmalloc_caches+0xe3/0xfd
|kmem_cache_init+0x14f/0x1f0
|start_kernel+0x1e7/0x3b3
|x86_64_start_reservations+0x2a/0x2c
|x86_64_start_kernel+0x13d/0x14c
|verify_cpu+0x0/0xfc
|
| -> #0 (batched_entropy_reset_lock){+.+...}:
|__lock_acquire+0x11b4/0x1320
|lock_acquire+0xb5/0x2b0
|rt_write_lock+0x26/0x40
|rt_write_lock_irqsave+0x9/0x10
|invalidate_batched_entropy+0x28/0xb0
|crng_fast_load+0xb5/0xe0
|add_interrupt_randomness+0x16c/0x1a0
|irq_thread+0x15c/0x1e0
|kthread+0x112/0x150
|ret_from_fork+0x31/0x40

We have the path add_interrupt_randomness() -> crng_fast_load() which
take
  primary_crng.lock -> batched_entropy_reset_lock
and we have get_random_uXX() -> extract_crng() which take the locks in
opposite order:
  batched_entropy_reset_lock -> crng->lock

however batched_entropy_reset_lock() is only taken if "crng_init < 2" so
it is possible RT hits this constraint more reliably.

> ---
>  drivers/char/random.c | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index a561f0c2f428..d35da1603e12 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1,6 +1,9 @@
>  /*
>   * random.c -- A strong random number generator
>   *
> + * Copyright (C) 2017 Jason A. Donenfeld . All
> + * Rights Reserved.
> + *
>   * Copyright Matt Mackall , 2003, 2004, 2005
>   *
>   * Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999.  All
> @@ -762,6 +765,8 @@ static DECLARE_WAIT_QUEUE_HEAD(crng_init_wait);
>  static struct crng_state **crng_node_pool __read_mostly;
>  #endif
>  
> +static void invalidate_batched_entropy(void);
> +
>  static void crng_initialize(struct crng_state *crng)
>  {
>   int i;
> @@ -799,6 +804,7 @@ static int crng_fast_load(const char *cp, size_t len)
>   cp++; crng_init_cnt++; len--;
>   }
>   if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
> + invalidate_batched_entropy();
>   crng_init = 1;
>   wake_up_interruptible(_init_wait);
>   pr_notice("random: fast init done\n");
> @@ -836,6 +842,7 @@ static void crng_reseed(struct crng_state *crng, struct 
> entropy_store *r)
>   memzero_explicit(, sizeof(buf));
>   crng->init_time = jiffies;
>   if (crng == _crng && crng_init < 2) {
> + invalidate_batched_entropy();
>   crng_init = 2;
>   process_random_ready_list();
>   wake_up_interruptible(_init_wait);
> @@ -2023,6 +2030,7 @@ struct batched_entropy {
>   };
>   unsigned int position;
>  };
> +static rwlock_t batched_entropy_reset_lock = 
> __RW_LOCK_UNLOCKED(batched_entropy_reset_lock);
>  
>  /*
>   * Get a random word for internal kernel use only. The quality of the random
> @@ -2033,6 +2041,8 @@ static DEFINE_PER_CPU(struct batched_entropy, 
> batched_entropy_u64);
>  u64 get_random_u64(void)
>  {
>   u64 ret;
> + const bool use_lock = READ_ONCE(crng_init) < 2;
> + unsigned long flags = 0;
>   struct 

[PATCH 13/21] padata: Convert to hotplug state machine

[Sebastian Andrzej Siewior]

Install the callbacks via the state machine. CPU-hotplug multinstance support
is used with the nocalls() version. Maybe parts of padata_alloc() could be
moved into the online callback so that we could invoke ->startup callback for
instance and drop get_online_cpus().

Cc: Steffen Klassert <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(-)

diff --git a/include/linux/padata.h b/include/linux/padata.h
index 113ee626a4dc..0f9e567d5e15 100644
--- a/include/linux/padata.h
+++ b/include/linux/padata.h
@@ -151,7 +151,7 @@ struct parallel_data {
  * @flags: padata flags.
  */
 struct padata_instance {
-   struct notifier_blockcpu_notifier;
+   struct hlist_nodenode;
struct workqueue_struct *wq;
struct parallel_data*pd;
struct padata_cpumask   cpumask;
diff --git a/kernel/padata.c b/kernel/padata.c
index 993278895ccc..7848f0566403 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_OBJ_NUM 1000
 
@@ -769,52 +770,43 @@ static inline int pinst_has_cpu(struct padata_instance 
*pinst, int cpu)
cpumask_test_cpu(cpu, pinst->cpumask.cbcpu);
 }
 
-
-static int padata_cpu_callback(struct notifier_block *nfb,
-  unsigned long action, void *hcpu)
+static int padata_cpu_online(unsigned int cpu, struct hlist_node *node)
 {
-   int err;
struct padata_instance *pinst;
-   int cpu = (unsigned long)hcpu;
+   int ret;
 
-   pinst = container_of(nfb, struct padata_instance, cpu_notifier);
+   pinst = hlist_entry_safe(node, struct padata_instance, node);
+   if (!pinst_has_cpu(pinst, cpu))
+   return 0;
 
-   switch (action) {
-   case CPU_ONLINE:
-   case CPU_ONLINE_FROZEN:
-   case CPU_DOWN_FAILED:
-   case CPU_DOWN_FAILED_FROZEN:
-   if (!pinst_has_cpu(pinst, cpu))
-   break;
-   mutex_lock(>lock);
-   err = __padata_add_cpu(pinst, cpu);
-   mutex_unlock(>lock);
-   if (err)
-   return notifier_from_errno(err);
-   break;
-
-   case CPU_DOWN_PREPARE:
-   case CPU_DOWN_PREPARE_FROZEN:
-   case CPU_UP_CANCELED:
-   case CPU_UP_CANCELED_FROZEN:
-   if (!pinst_has_cpu(pinst, cpu))
-   break;
-   mutex_lock(>lock);
-   err = __padata_remove_cpu(pinst, cpu);
-   mutex_unlock(>lock);
-   if (err)
-   return notifier_from_errno(err);
-   break;
-   }
-
-   return NOTIFY_OK;
+   mutex_lock(>lock);
+   ret = __padata_add_cpu(pinst, cpu);
+   mutex_unlock(>lock);
+   return ret;
 }
+
+static int padata_cpu_prep_down(unsigned int cpu, struct hlist_node *node)
+{
+   struct padata_instance *pinst;
+   int ret;
+
+   pinst = hlist_entry_safe(node, struct padata_instance, node);
+   if (!pinst_has_cpu(pinst, cpu))
+   return 0;
+
+   mutex_lock(>lock);
+   ret = __padata_remove_cpu(pinst, cpu);
+   mutex_unlock(>lock);
+   return ret;
+}
+
+static enum cpuhp_state hp_online;
 #endif
 
 static void __padata_free(struct padata_instance *pinst)
 {
 #ifdef CONFIG_HOTPLUG_CPU
-   unregister_hotcpu_notifier(>cpu_notifier);
+   cpuhp_state_remove_instance_nocalls(hp_online, >node);
 #endif
 
padata_stop(pinst);
@@ -1012,11 +1004,8 @@ struct padata_instance *padata_alloc(struct 
workqueue_struct *wq,
mutex_init(>lock);
 
 #ifdef CONFIG_HOTPLUG_CPU
-   pinst->cpu_notifier.notifier_call = padata_cpu_callback;
-   pinst->cpu_notifier.priority = 0;
-   register_hotcpu_notifier(>cpu_notifier);
+   cpuhp_state_add_instance_nocalls(hp_online, >node);
 #endif
-
return pinst;
 
 err_free_masks:
@@ -1039,3 +1028,26 @@ void padata_free(struct padata_instance *pinst)
kobject_put(>kobj);
 }
 EXPORT_SYMBOL(padata_free);
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+static __init int padata_driver_init(void)
+{
+   int ret;
+
+   ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "padata:online",
+ padata_cpu_online,
+ padata_cpu_prep_down);
+   if (ret < 0)
+   return ret;
+   hp_online = ret;
+   return 0;
+}
+module_init(padata_driver_init);
+
+static __exit void padata_driver_exit(void)
+{
+   cpuhp_remove_multi_state(hp_online);
+}
+module_exit(padata_driver_exit);
+#endif
-- 
2.9.3

--
To unsubscribe from this li

[PATCH] crypto/ccp: remove rwlocks_types.h

[Sebastian Andrzej Siewior]

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/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 4dbc18727235..2a8ad712a5f2 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.8.1

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

[PATCH] crypto/arc4: now arc needs blockcipher support

[Sebastian Andrzej Siewior]

Since commit ce6dd368 (crypto: arc4 - improve performance by adding
ecb(arc4)) we need to pull in a blkcipher.

|ERROR: crypto_blkcipher_type [crypto/arc4.ko] undefined!
|ERROR: blkcipher_walk_done [crypto/arc4.ko] undefined!
|ERROR: blkcipher_walk_virt [crypto/arc4.ko] undefined!

Signed-off-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 insertion(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 2c1c2df..cefbe15 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -593,7 +593,7 @@ config CRYPTO_ANUBIS
 
 config CRYPTO_ARC4
tristate ARC4 cipher algorithm
-   select CRYPTO_ALGAPI
+   select CRYPTO_BLKCIPHER
help
  ARC4 cipher algorithm.
 
-- 
1.7.10

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

Re: mv_cesa hash functions

[Sebastian Andrzej Siewior]

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 the 3.2.4 kernel's mv_cesa in Debian Wheezy on a 
  Marvell Kirkwood system, I've noticed the following kernel output when I 
  load the mv_cesa kernel module:
  
  [490889.448060] alg: hash: Test 1 failed for mv-sha1
  [490889.452786] : c1 94 3f 2e a2 41 ce 88 d5 47 07 43 c4 a8 17 5d
  [490889.459368] 0010: 77 e8 47 ca
  [490889.464321] alg: hash: Test 1 failed for mv-hmac-sha1
  [490889.469493] : 06 71 4d 7c cc cc b5 cf 1b d6 c7 ab d0 25 c4 21
  [490889.476068] 0010: 66 0b 8e 70
  Using SHA1 in a ssl/tls handshake fails in tests with mv_cesa loaded, which 
  might be related to this.
 
 
 It might be related. I noticed the same issue in userspace with
 /dev/crypto. It can be solved by adding a 50 ms delay after the
 encryption, decryption and hashing operations. (a delay less than that
 didn't work).

It might a missing cache flush before/after the opration or before passing
the data to userland. I've seen that some hash operation fail which are not
perfromed in one go but via the start, update, end path. However I had no
time to get to the bottom of this.

 
 regards,
 Nikos

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  http://vger.kernel.org/majordomo-info.html

Re: RFC: kcrypto - (yet another) user space interface

[Sebastian Andrzej Siewior]

* 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 talks about the perfect userspace crypto api and
rejections implementations because they are not perfect enough. I don't
believe there is such thing as a perfect crypto api. Other operating
systems have a userspace crypto API (maybe not perfect) but linux
hasn't. I don't think this is the way to go.

Phil asked me for my opinion and he got it. The fundumention problems
from what I've seen was the interface:
- kernel structs which are exposed to userland which limit the
  parameters. For instance the iv was limited to 16 bytes while we have
  allready algos with a much longer iv.
- the interface was using write()/poll()/read() and get_user_pages(). I
  pointed out Herbert's opinion about this and the alternative. So this
  _was_ allready discsussed.

regards,
Nikos

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  http://vger.kernel.org/majordomo-info.html

Re: RFC: kcrypto - (yet another) user space interface

[Sebastian Andrzej Siewior]

* 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 user memory. So no
get_user_pages() then :)

I think that is the way to go.

[0] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2656
[1] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2658

Phil

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  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] crypto: Alchemy AES engine driver

[Sebastian Andrzej Siewior]

* 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: setkey failed on test 3 for cbc-aes-alchemy: flags=0
alg: skcipher: Failed to load transform for cbc(aes): -2
alg: skcipher: Failed to load transform for cbc(aes): -2
tcrypt: one or more tests failed!
FATAL: Error inserting tcrypt 
(/lib/modules/2.6.34-rc6-db1200-00214-g9f84af9/kernel/crypto/tcrypt.ko): 
Unknown symbol in module, or unknown parameter (see dmesg)

The error in test 3 for cbc-aes-alchemy probably comes from the inability
to process keys larger than 128 bits.
You have to fix this, you have to be able to handle other keys as well.
In case your hardware does not support it, you have to handle this in
software. Look at the geode driver, via  or s390. All of them have
fallbacks for. If you fail the self test, you driver will no be used
afaik.

Please have a look.
 Thanks!

diff --git a/drivers/crypto/alchemy-aes.c b/drivers/crypto/alchemy-aes.c
new file mode 100644
index 000..14e8ace
--- /dev/null
+++ b/drivers/crypto/alchemy-aes.c
+static int __init alchemy_aes_load(void)
+{
+  /* FIXME: hier sollte auch noch der PRId des prozessors getestet
+   * werden; Au1210 (0x0503) und einige Au1300 haben lt. Daten-
+   * blatt keine AES engine.
+   */
You German right? You should handle this in SoC code. So if you figure
out, that you have an engine here you add the device. If you don't have
it you don't do it and the probe call won't be called. Also the module
won't be loaded by udev.

+  /* need to do 8bit accesses to memory to get correct data */
+  __alchemy_aes_memid = au1xxx_ddma_add_device(alchemy_aes_mem_dbdev);
+  if (!__alchemy_aes_memid)
+  return -ENODEV;
What does it do? You don't want to add devices here. If you need
something additional do it in SoC code and pass it via platform_data.

+
+  return platform_driver_register(alchemy_aes_driver);
+}
+

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  http://vger.kernel.org/majordomo-info.html

Re: Test tools for crypt accelerators?

[Sebastian Andrzej Siewior]

* 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

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Sebastian Andrzej Siewior]

* 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 unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* 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 possible, please post some patches which describe the user land
interface.

For IPSec I use this[0] shell script which sets up a connection. Good for
testing :) So you need two boxes, start the script on both machines and
the first ping that reached my orion box triggered that error. I just
sent something that looked like a fix.

I enabled list and sg debugging and a flood ping triggered a couple of
warning. Could you please look at this?

IPsec requests authenc(hmac(sha1),cbc(aes)) so right now it reqeusts two
cesa provided algorithms. A single ping results in around 30ms RTT.
Disabling hmac(sha1) gives me less than 1ms.
Implementing authenc() for IPsec should speed things up. Right I'm stuck
with hacking DMA support.

For now I think lowering priority of hmac() should fix the problem. A
direct request mv-hmac-sha1 should still returned the mv driver. What
do you thing?

Need to run now

Thanks,
Uri.

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  http://vger.kernel.org/majordomo-info.html

Re: Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* 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...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Crypto: geode-aes: Fix some code style issues

[Sebastian Andrzej Siewior]

* 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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] crypto/testmgr: add testing for arc4 based on ecb(arc4)

[Sebastian Andrzej Siewior]

* 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 alg_test_arc4 that computes the IV
before calling alg_test_skcipher.

I take a look at this.

Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto: add blkcipher implementation of ARC4

[Sebastian Andrzej Siewior]

* 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 getting arc4_setup_iv to do all the legwork
and turn it into a real IV? Then we don't need any checks on the
data path.
So arc4_setup_iv() should do what the internal arc4_ivsetup() does and
we change void to int and check the keysize in there right? The problem
here is that we are bounded to *this* implementation of the algorithm
and are not able to replace it with a different implementation. Not that
this is likely to happen for RC4 but it may be true for other stream
ciphers.

 While we are here, the .setkey() callback could be removed, couldn't it?
 It returns 0 even it is doing nothing what looks kinda wrong. However it
 shouldn't be called at all since min/max key is 0. Any objections on
 that?

I'm pretty sure testmgr will call setkey even for keylen == 0, no?
Prior patch #3 it has no test case so it should not test it at all.
Patch #3 adds a flag in order to distinguish it. You want to look at
patch #3 now :)


Thanks,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto: add blkcipher implementation of ARC4

[Sebastian Andrzej Siewior]

* 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 break for me on x86_64 (whether I'm compiling
modules or a solid kernel), and even though the potential name conflict
Take a look at
- sd_mod_init
- via_init
- watchdog_init

just to name a few. There is no conflict because those functions are not
global. The only problem you have is in the backtrace since you can't
distinguish them.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto: add blkcipher implementation of ARC4

[Sebastian Andrzej Siewior]

* 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  256; i++)
 +iv-iv.S[i] = i;
 +
 +for (i = 0; i  256; i++)
 +{
 +u8 a = iv-iv.S[i];
 +j = (j + in_key[k] + a)  0xff;
 +iv-iv.S[i] = iv-iv.S[j];
 +iv-iv.S[j] = a;
 +if (++k = key_len)
 +k = 0;
 +}
 +}
 +
 +static void arc4_ivsetup(struct arc4_iv *iv)
 +{
 +struct arc4_iv tmp_iv;
 +
 +if (iv-type == ARC4_TYPE_IV)
 +return;
 +
 +memcpy(tmp_iv, iv, sizeof(tmp_iv));
 +arc4_key_to_iv(tmp_iv.key.key, tmp_iv.key.key_len, iv);
 +iv-type = ARC4_TYPE_IV;
 +}

We need to verify that 1 = key_len = 256.
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.

While we are here, the .setkey() callback could be removed, couldn't it?
It returns 0 even it is doing nothing what looks kinda wrong. However it
shouldn't be called at all since min/max key is 0. Any objections on
that?


Cheers,

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  http://vger.kernel.org/majordomo-info.html

[PATCH v2] crypto: add blkcipher implementation of ARC4

[Sebastian Andrzej Siewior]

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
---
 crypto/Kconfig|   13 
 crypto/Makefile   |1 +
 crypto/arc4blk.c  |  150 +
 crypto/testmgr.h  |3 +-
 include/crypto/arc4.h |   26 +
 5 files changed, 192 insertions(+), 1 deletions(-)
 create mode 100644 crypto/arc4blk.c
 create mode 100644 include/crypto/arc4.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 81c185a..be9add2 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -570,6 +570,19 @@ config CRYPTO_ARC4
  WEP, but it should not be for other purposes because of the
  weakness of the algorithm.
 
+config CRYPTO_ARC4BLK
+   tristate ARC4 cipher algorithm (alternative implemenation)
+   select CRYPTO_BLKCIPHER
+   help
+ ARC4 cipher algorithm. This is an alternative ARC4 implementation 
which
+ will replace the other ARC4 implementation once all in-kernel users 
are
+ converted.
+
+ ARC4 is a stream cipher using keys ranging from 8 bits to 2048
+ bits in length.  This algorithm is required for driver-based
+ WEP, but it should not be for other purposes because of the
+ weakness of the algorithm.
+
 config CRYPTO_BLOWFISH
tristate Blowfish cipher algorithm
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 1f15112..11300e3 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia.o
 obj-$(CONFIG_CRYPTO_CAST5) += cast5.o
 obj-$(CONFIG_CRYPTO_CAST6) += cast6.o
 obj-$(CONFIG_CRYPTO_ARC4) += arc4cip.o
+obj-$(CONFIG_CRYPTO_ARC4BLK) += arc4blk.o
 obj-$(CONFIG_CRYPTO_TEA) += tea.o
 obj-$(CONFIG_CRYPTO_KHAZAD) += khazad.o
 obj-$(CONFIG_CRYPTO_ANUBIS) += anubis.o
diff --git a/crypto/arc4blk.c b/crypto/arc4blk.c
new file mode 100644
index 000..bdf938a
--- /dev/null
+++ b/crypto/arc4blk.c
@@ -0,0 +1,150 @@
+/*
+ * Cryptographic API
+ *
+ * ARC4 Cipher Algorithm
+ *
+ * Jon Oberheide j...@oberheide.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include linux/module.h
+#include linux/init.h
+#include crypto/algapi.h
+#include crypto/arc4.h
+
+#define ARC4_MIN_KEY_SIZE  1
+#define ARC4_MAX_KEY_SIZE  256
+#define ARC4_BLOCK_SIZE1
+
+static int arc4_set_key(struct crypto_tfm *tfm, const u8 *in_key,
+   unsigned int key_len)
+{
+   /*
+* ARC4 is special: The user should supply an IV as struct arc4_iv and
+* fill either the key or the iv.
+*/
+   return 0;
+}
+
+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  256; i++)
+   iv-iv.S[i] = i;
+
+   for (i = 0; i  256; i++)
+   {
+   u8 a = iv-iv.S[i];
+   j = (j + in_key[k] + a)  0xff;
+   iv-iv.S[i] = iv-iv.S[j];
+   iv-iv.S[j] = a;
+   if (++k = key_len)
+   k = 0;
+   }
+}
+
+static void arc4_ivsetup(struct arc4_iv *iv)
+{
+   struct arc4_iv tmp_iv;
+
+   if (iv-type == ARC4_TYPE_IV)
+   return;
+
+   memcpy(tmp_iv, iv, sizeof(tmp_iv));
+   arc4_key_to_iv(tmp_iv.key.key, tmp_iv.key.key_len, iv);
+   iv-type = ARC4_TYPE_IV;
+}
+
+static int arc4_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
+   struct scatterlist *src, unsigned int nbytes)
+{
+   struct blkcipher_walk walk;
+   struct arc4_iv *aiv;
+   u8 *S;
+   u8 x;
+   u8 y;
+   u8 a, b;
+   int ret;
+
+   blkcipher_walk_init(walk, dst, src, nbytes);
+   ret = blkcipher_walk_virt(desc, walk);
+   if (ret)
+   return ret;
+
+   aiv = (struct arc4_iv *)walk.iv;
+   arc4_ivsetup(aiv);
+
+   S = aiv-iv.S;
+   x = aiv-iv.x;
+   y = aiv-iv.y;
+
+   while (walk.nbytes) {
+   u8 *in = walk.src.virt.addr;
+   u8 *out = walk.dst.virt.addr;
+   u32 i;
+
+   for (i = 0; i  walk.nbytes; i++) {
+   a = S[x];
+   y = (y + a)  0xff;
+   b = S[y];
+   S[x] = b;
+   S[y] = a;
+   x = (x + 1)  0xff;
+   *out = *in ^ S[(a + b)  0xff];
+
+   in++;
+   out

[PATCH 1/7] crypto: rename arc4

[Sebastian Andrzej Siewior]

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 = arc4cip.c} |1 +
 2 files changed, 2 insertions(+), 1 deletions(-)
 rename crypto/{arc4.c = arc4cip.c} (98%)

diff --git a/crypto/Makefile b/crypto/Makefile
index 9e8f619..1f15112 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -67,7 +67,7 @@ obj-$(CONFIG_CRYPTO_AES) += aes_generic.o
 obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia.o
 obj-$(CONFIG_CRYPTO_CAST5) += cast5.o
 obj-$(CONFIG_CRYPTO_CAST6) += cast6.o
-obj-$(CONFIG_CRYPTO_ARC4) += arc4.o
+obj-$(CONFIG_CRYPTO_ARC4) += arc4cip.o
 obj-$(CONFIG_CRYPTO_TEA) += tea.o
 obj-$(CONFIG_CRYPTO_KHAZAD) += khazad.o
 obj-$(CONFIG_CRYPTO_ANUBIS) += anubis.o
diff --git a/crypto/arc4.c b/crypto/arc4cip.c
similarity index 98%
rename from crypto/arc4.c
rename to crypto/arc4cip.c
index 8be47e1..bf04659 100644
--- a/crypto/arc4.c
+++ b/crypto/arc4cip.c
@@ -102,3 +102,4 @@ module_exit(arc4_exit);
 MODULE_LICENSE(GPL);
 MODULE_DESCRIPTION(ARC4 Cipher Algorithm);
 MODULE_AUTHOR(Jon Oberheide j...@oberheide.org);
+MODULE_ALIAS(arc4);
-- 
1.6.6

--
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

Convert arc4 from a cipher into a block cipher

[Sebastian Andrzej Siewior]

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
- mac80211 was tested with zd1211rw

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  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] net/wireless: switch lib80211_crypt_wep from arc4 to arc4blk

[Sebastian Andrzej Siewior]

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 Siewior sebast...@breakpoint.cc
---
 drivers/net/wireless/hostap/Kconfig  |3 ---
 drivers/net/wireless/ipw2x00/Kconfig |3 ---
 net/wireless/Kconfig |2 ++
 net/wireless/lib80211_crypt_wep.c|   11 +++
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/hostap/Kconfig 
b/drivers/net/wireless/hostap/Kconfig
index 287d827..dab2c6b 100644
--- a/drivers/net/wireless/hostap/Kconfig
+++ b/drivers/net/wireless/hostap/Kconfig
@@ -4,11 +4,8 @@ config HOSTAP
select WEXT_SPY
select WEXT_PRIV
select CRYPTO
-   select CRYPTO_ARC4
-   select CRYPTO_ECB
select CRYPTO_AES
select CRYPTO_MICHAEL_MIC
-   select CRYPTO_ECB
select CRC32
select LIB80211
select LIB80211_CRYPT_WEP
diff --git a/drivers/net/wireless/ipw2x00/Kconfig 
b/drivers/net/wireless/ipw2x00/Kconfig
index 2715b10..6fe1995 100644
--- a/drivers/net/wireless/ipw2x00/Kconfig
+++ b/drivers/net/wireless/ipw2x00/Kconfig
@@ -158,11 +158,8 @@ config LIBIPW
select WIRELESS_EXT
select WEXT_SPY
select CRYPTO
-   select CRYPTO_ARC4
-   select CRYPTO_ECB
select CRYPTO_AES
select CRYPTO_MICHAEL_MIC
-   select CRYPTO_ECB
select CRC32
select LIB80211
select LIB80211_CRYPT_WEP
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 119f1eb..267eb42 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -141,6 +141,8 @@ config LIB80211
  you want this built into your kernel.
 
 config LIB80211_CRYPT_WEP
+   select CRYPTO
+   select CRYPTO_ARC4BLK
tristate
 
 config LIB80211_CRYPT_CCMP
diff --git a/net/wireless/lib80211_crypt_wep.c 
b/net/wireless/lib80211_crypt_wep.c
index 6d41e05..3759e46 100644
--- a/net/wireless/lib80211_crypt_wep.c
+++ b/net/wireless/lib80211_crypt_wep.c
@@ -23,6 +23,7 @@
 #include net/lib80211.h
 
 #include linux/crypto.h
+#include crypto/arc4.h
 #include linux/crc32.h
 
 MODULE_AUTHOR(Jouni Malinen);
@@ -48,7 +49,7 @@ static void *lib80211_wep_init(int keyidx)
goto fail;
priv-key_idx = keyidx;
 
-   priv-tx_tfm = crypto_alloc_blkcipher(ecb(arc4), 0, CRYPTO_ALG_ASYNC);
+   priv-tx_tfm = crypto_alloc_blkcipher(arc4, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv-tx_tfm)) {
printk(KERN_DEBUG lib80211_crypt_wep: could not allocate 
   crypto API arc4\n);
@@ -56,7 +57,7 @@ static void *lib80211_wep_init(int keyidx)
goto fail;
}
 
-   priv-rx_tfm = crypto_alloc_blkcipher(ecb(arc4), 0, CRYPTO_ALG_ASYNC);
+   priv-rx_tfm = crypto_alloc_blkcipher(arc4, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv-rx_tfm)) {
printk(KERN_DEBUG lib80211_crypt_wep: could not allocate 
   crypto API arc4\n);
@@ -139,6 +140,7 @@ static int lib80211_wep_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 {
struct lib80211_wep_data *wep = priv;
struct blkcipher_desc desc = { .tfm = wep-tx_tfm };
+   struct arc4_iv *iv = crypto_blkcipher_crt(wep-tx_tfm)-iv;
u32 crc, klen, len;
u8 *pos, *icv;
struct scatterlist sg;
@@ -170,7 +172,7 @@ static int lib80211_wep_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
icv[2] = crc  16;
icv[3] = crc  24;
 
-   crypto_blkcipher_setkey(wep-tx_tfm, key, klen);
+   arc4_setup_iv(iv, key, klen);
sg_init_one(sg, pos, len + 4);
return crypto_blkcipher_encrypt(desc, sg, sg, len + 4);
 }
@@ -186,6 +188,7 @@ static int lib80211_wep_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 {
struct lib80211_wep_data *wep = priv;
struct blkcipher_desc desc = { .tfm = wep-rx_tfm };
+   struct arc4_iv *iv = crypto_blkcipher_crt(wep-rx_tfm)-iv;
u32 crc, klen, plen;
u8 key[WEP_KEY_LEN + 3];
u8 keyidx, *pos, icv[4];
@@ -210,7 +213,7 @@ static int lib80211_wep_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
/* Apply RC4 to data and compute CRC32 over decrypted data */
plen = skb-len - hdr_len - 8;
 
-   crypto_blkcipher_setkey(wep-rx_tfm, key, klen);
+   arc4_setup_iv(iv, key, klen);
sg_init_one(sg, pos, plen + 4);
if (crypto_blkcipher_decrypt(desc, sg, sg, plen + 4))
return -7;
-- 
1.6.6

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

[PATCH 3/7] crypto/testmgr: add testing for arc4 based on ecb(arc4)

[Sebastian Andrzej Siewior]

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/testmgr.c
+++ b/crypto/testmgr.c
@@ -20,6 +20,7 @@
 #include linux/slab.h
 #include linux/string.h
 #include crypto/rng.h
+#include crypto/arc4.h
 
 #include internal.h
 #include testmgr.h
@@ -44,6 +45,7 @@
 /*
 * Used by test_cipher()
 */
+#define CRYPT_ARC4 2
 #define ENCRYPT 1
 #define DECRYPT 0
 
@@ -717,7 +719,7 @@ out_nobuf:
return ret;
 }
 
-static int test_skcipher(struct crypto_ablkcipher *tfm, int enc,
+static int test_skcipher(struct crypto_ablkcipher *tfm, int mode,
 struct cipher_testvec *template, unsigned int tcount)
 {
const char *algo =
@@ -736,7 +738,7 @@ static int test_skcipher(struct crypto_ablkcipher *tfm, int 
enc,
if (testmgr_alloc_buf(xbuf))
goto out_nobuf;
 
-   if (enc == ENCRYPT)
+   if (mode == ENCRYPT)
e = encryption;
else
e = decryption;
@@ -775,7 +777,11 @@ static int test_skcipher(struct crypto_ablkcipher *tfm, 
int enc,
crypto_ablkcipher_set_flags(
tfm, CRYPTO_TFM_REQ_WEAK_KEY);
 
-   ret = crypto_ablkcipher_setkey(tfm, template[i].key,
+   if (mode == CRYPT_ARC4)
+   arc4_setup_iv((struct arc4_iv *)iv,
+   template[i].key, template[i].klen);
+   else
+   ret = crypto_ablkcipher_setkey(tfm, 
template[i].key,
   template[i].klen);
if (!ret == template[i].fail) {
printk(KERN_ERR alg: skcipher: setkey failed 
@@ -789,7 +795,7 @@ static int test_skcipher(struct crypto_ablkcipher *tfm, int 
enc,
 
ablkcipher_request_set_crypt(req, sg, sg,
 template[i].ilen, iv);
-   ret = enc ?
+   ret = mode ?
crypto_ablkcipher_encrypt(req) :
crypto_ablkcipher_decrypt(req);
 
@@ -839,7 +845,11 @@ static int test_skcipher(struct crypto_ablkcipher *tfm, 
int enc,
crypto_ablkcipher_set_flags(
tfm, CRYPTO_TFM_REQ_WEAK_KEY);
 
-   ret = crypto_ablkcipher_setkey(tfm, template[i].key,
+   if (mode == CRYPT_ARC4)
+   arc4_setup_iv((struct arc4_iv *)iv,
+   template[i].key, template[i].klen);
+   else
+   ret = crypto_ablkcipher_setkey(tfm, 
template[i].key,
   template[i].klen);
if (!ret == template[i].fail) {
printk(KERN_ERR alg: skcipher: setkey failed 
@@ -876,7 +886,7 @@ static int test_skcipher(struct crypto_ablkcipher *tfm, int 
enc,
ablkcipher_request_set_crypt(req, sg, sg,
template[i].ilen, iv);
 
-   ret = enc ?
+   ret = mode ?
crypto_ablkcipher_encrypt(req) :
crypto_ablkcipher_decrypt(req);
 
@@ -1316,11 +1326,12 @@ out:
return err;
 }
 
-static int alg_test_skcipher(const struct alg_test_desc *desc,
-const char *driver, u32 type, u32 mask)
+static int _alg_test_skcipher(const struct alg_test_desc *desc,
+const char *driver, u32 type, u32 mask, u32 arc4)
 {
struct crypto_ablkcipher *tfm;
int err = 0;
+   int mode;
 
tfm = crypto_alloc_ablkcipher(driver, type, mask);
if (IS_ERR(tfm)) {
@@ -1329,15 +1340,17 @@ static int alg_test_skcipher(const struct alg_test_desc 
*desc,
return PTR_ERR(tfm);
}
 
+   mode = arc4 ? CRYPT_ARC4 : ENCRYPT;
if (desc-suite.cipher.enc.vecs) {
-   err = test_skcipher(tfm, ENCRYPT, desc-suite.cipher.enc.vecs,
+   err = test_skcipher(tfm, mode , desc-suite.cipher.enc.vecs,
desc-suite.cipher.enc.count);
if (err)
goto out;
}
 
+   mode = arc4 ? CRYPT_ARC4 : DECRYPT;
if (desc-suite.cipher.dec.vecs)
-   err = test_skcipher(tfm, DECRYPT, desc-suite.cipher.dec.vecs,
+   err = test_skcipher(tfm, mode, desc-suite.cipher.dec.vecs,
desc-suite.cipher.dec.count);
 
 out

[PATCH 4/7] net/wireless: switch lib80211_crypt_tkip from arc4 to arc4blk

[Sebastian Andrzej Siewior]

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/wireless/lib80211_crypt_tkip.c |   11 +++
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 90e93a5..119f1eb 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -147,6 +147,8 @@ config LIB80211_CRYPT_CCMP
tristate
 
 config LIB80211_CRYPT_TKIP
+   select CRYPTO
+   select CRYPTO_ARC4BLK
tristate
 
 config LIB80211_DEBUG
diff --git a/net/wireless/lib80211_crypt_tkip.c 
b/net/wireless/lib80211_crypt_tkip.c
index c362873..089f84f 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -28,6 +28,7 @@
 #include net/iw_handler.h
 
 #include linux/crypto.h
+#include crypto/arc4.h
 #include linux/crc32.h
 
 #include net/lib80211.h
@@ -94,7 +95,7 @@ static void *lib80211_tkip_init(int key_idx)
 
priv-key_idx = key_idx;
 
-   priv-tx_tfm_arc4 = crypto_alloc_blkcipher(ecb(arc4), 0,
+   priv-tx_tfm_arc4 = crypto_alloc_blkcipher(arc4, 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(priv-tx_tfm_arc4)) {
printk(KERN_DEBUG lib80211_crypt_tkip: could not allocate 
@@ -112,7 +113,7 @@ static void *lib80211_tkip_init(int key_idx)
goto fail;
}
 
-   priv-rx_tfm_arc4 = crypto_alloc_blkcipher(ecb(arc4), 0,
+   priv-rx_tfm_arc4 = crypto_alloc_blkcipher(arc4, 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(priv-rx_tfm_arc4)) {
printk(KERN_DEBUG lib80211_crypt_tkip: could not allocate 
@@ -360,6 +361,7 @@ static int lib80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 {
struct lib80211_tkip_data *tkey = priv;
struct blkcipher_desc desc = { .tfm = tkey-tx_tfm_arc4 };
+   struct arc4_iv *iv = crypto_blkcipher_crt(tkey-tx_tfm_arc4)-iv;
int len;
u8 rc4key[16], *pos, *icv;
u32 crc;
@@ -392,7 +394,7 @@ static int lib80211_tkip_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
icv[2] = crc  16;
icv[3] = crc  24;
 
-   crypto_blkcipher_setkey(tkey-tx_tfm_arc4, rc4key, 16);
+   arc4_setup_iv(iv, rc4key, 16);
sg_init_one(sg, pos, len + 4);
return crypto_blkcipher_encrypt(desc, sg, sg, len + 4);
 }
@@ -414,6 +416,7 @@ static int lib80211_tkip_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 {
struct lib80211_tkip_data *tkey = priv;
struct blkcipher_desc desc = { .tfm = tkey-rx_tfm_arc4 };
+   struct arc4_iv *iv = crypto_blkcipher_crt(tkey-rx_tfm_arc4)-iv;
u8 rc4key[16];
u8 keyidx, *pos;
u32 iv32;
@@ -485,7 +488,7 @@ static int lib80211_tkip_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 
plen = skb-len - hdr_len - 12;
 
-   crypto_blkcipher_setkey(tkey-rx_tfm_arc4, rc4key, 16);
+   arc4_setup_iv(iv, rc4key, 16);
sg_init_one(sg, pos, plen + 4);
if (crypto_blkcipher_decrypt(desc, sg, sg, plen + 4)) {
if (net_ratelimit()) {
-- 
1.6.6

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

[PATCH 7/7] net/ppp_mppe: convert from arc4 to arc4blk

[Sebastian Andrzej Siewior]

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(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd9a09c..4b5dd86 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -3075,8 +3075,7 @@ config PPP_MPPE
depends on PPP  EXPERIMENTAL
select CRYPTO
select CRYPTO_SHA1
-   select CRYPTO_ARC4
-   select CRYPTO_ECB
+   select CRYPTO_ARC4BLK
---help---
  Support for the MPPE Encryption protocol, as employed by the
 Microsoft Point-to-Point Tunneling Protocol.
diff --git a/drivers/net/ppp_mppe.c b/drivers/net/ppp_mppe.c
index 6d1a1b8..4deaf70 100644
--- a/drivers/net/ppp_mppe.c
+++ b/drivers/net/ppp_mppe.c
@@ -42,7 +42,6 @@
  *MOD_DEC_USAGE_COUNT/MOD_INC_USAGE_COUNT which are
  *deprecated in 2.6
  */
-
 #include linux/err.h
 #include linux/module.h
 #include linux/kernel.h
@@ -55,6 +54,7 @@
 #include linux/ppp_defs.h
 #include linux/ppp-comp.h
 #include linux/scatterlist.h
+#include crypto/arc4.h
 
 #include ppp_mppe.h
 
@@ -162,11 +162,11 @@ static void mppe_rekey(struct ppp_mppe_state * state, int 
initial_key)
 {
struct scatterlist sg_in[1], sg_out[1];
struct blkcipher_desc desc = { .tfm = state-arc4 };
+   struct arc4_iv *iv = crypto_blkcipher_crt(state-arc4)-iv;
 
get_new_key_from_sha(state);
if (!initial_key) {
-   crypto_blkcipher_setkey(state-arc4, state-sha1_digest,
-   state-keylen);
+   arc4_setup_iv(iv, state-sha1_digest, state-keylen);
sg_init_table(sg_in, 1);
sg_init_table(sg_out, 1);
setup_sg(sg_in, state-sha1_digest, state-keylen);
@@ -184,7 +184,7 @@ static void mppe_rekey(struct ppp_mppe_state * state, int 
initial_key)
state-session_key[1] = 0x26;
state-session_key[2] = 0x9e;
}
-   crypto_blkcipher_setkey(state-arc4, state-session_key, state-keylen);
+   arc4_setup_iv(iv, state-session_key, state-keylen);
 }
 
 /*
@@ -204,7 +204,7 @@ static void *mppe_alloc(unsigned char *options, int optlen)
goto out;
 
 
-   state-arc4 = crypto_alloc_blkcipher(ecb(arc4), 0, CRYPTO_ALG_ASYNC);
+   state-arc4 = crypto_alloc_blkcipher(arc4, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(state-arc4)) {
state-arc4 = NULL;
goto out_free;
@@ -712,7 +712,7 @@ static struct compressor ppp_mppe = {
 static int __init ppp_mppe_init(void)
 {
int answer;
-   if (!(crypto_has_blkcipher(ecb(arc4), 0, CRYPTO_ALG_ASYNC) 
+   if (!(crypto_has_blkcipher(arc4, 0, CRYPTO_ALG_ASYNC) 
  crypto_has_hash(sha1, 0, CRYPTO_ALG_ASYNC)))
return -ENODEV;
 
-- 
1.6.6

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

[PATCH 6/7] net/mac80211: convert wep from arc4 to arc4blk

[Sebastian Andrzej Siewior]

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 b/net/mac80211/Kconfig
index a10d508..d14fe06 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -2,8 +2,7 @@ config MAC80211
tristate Generic IEEE 802.11 Networking Stack (mac80211)
depends on CFG80211
select CRYPTO
-   select CRYPTO_ECB
-   select CRYPTO_ARC4
+   select CRYPTO_ARC4BLK
select CRYPTO_AES
select CRC32
---help---
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index 247123f..4314b50 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -17,6 +17,7 @@
 #include linux/err.h
 #include linux/mm.h
 #include linux/scatterlist.h
+#include crypto/arc4.h
 #include asm/unaligned.h
 
 #include net/mac80211.h
@@ -29,12 +30,12 @@ int ieee80211_wep_init(struct ieee80211_local *local)
/* start WEP IV from a random value */
get_random_bytes(local-wep_iv, WEP_IV_LEN);
 
-   local-wep_tx_tfm = crypto_alloc_blkcipher(ecb(arc4), 0,
+   local-wep_tx_tfm = crypto_alloc_blkcipher(arc4, 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(local-wep_tx_tfm))
return PTR_ERR(local-wep_tx_tfm);
 
-   local-wep_rx_tfm = crypto_alloc_blkcipher(ecb(arc4), 0,
+   local-wep_rx_tfm = crypto_alloc_blkcipher(arc4, 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(local-wep_rx_tfm)) {
crypto_free_blkcipher(local-wep_tx_tfm);
@@ -125,13 +126,14 @@ void ieee80211_wep_encrypt_data(struct crypto_blkcipher 
*tfm, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
 {
struct blkcipher_desc desc = { .tfm = tfm };
+   struct arc4_iv *iv = crypto_blkcipher_crt(tfm)-iv;
struct scatterlist sg;
__le32 icv;
 
icv = cpu_to_le32(~crc32_le(~0, data, data_len));
put_unaligned(icv, (__le32 *)(data + data_len));
 
-   crypto_blkcipher_setkey(tfm, rc4key, klen);
+   arc4_setup_iv(iv, rc4key, klen);
sg_init_one(sg, data, data_len + WEP_ICV_LEN);
crypto_blkcipher_encrypt(desc, sg, sg, sg.length);
 }
@@ -181,10 +183,11 @@ int ieee80211_wep_decrypt_data(struct crypto_blkcipher 
*tfm, u8 *rc4key,
   size_t klen, u8 *data, size_t data_len)
 {
struct blkcipher_desc desc = { .tfm = tfm };
+   struct arc4_iv *iv = crypto_blkcipher_crt(tfm)-iv;
struct scatterlist sg;
__le32 crc;
 
-   crypto_blkcipher_setkey(tfm, rc4key, klen);
+   arc4_setup_iv(iv, rc4key, klen);
sg_init_one(sg, data, data_len + WEP_ICV_LEN);
crypto_blkcipher_decrypt(desc, sg, sg, sg.length);
 
-- 
1.6.6

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

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* Herbert Xu | 2010-02-23 08:32:39 [+0800]:

If you can find a way that allows arc4 to be used by multiple
threads at the same time while storing less than 258 bytes in
each thread, please let me know :)
:)

No, what you could do is structure the IV differently based on the
flag:

struct arc4_iv {
   union {
   struct key {
   u8 key[256];
   u16 keylen;
   };
   struct iv {
   u8 S[256];
   u8 x, y;
   };
   };
   u8 type;
};

This relies on the fact that we never use more than 256 bytes in
the key so limiting its length is OK.

Okay. So so are we talking about something like that below then? This is
untested and I break other users bexcept lib80211_crypt_tkip. 

the state has been moved from ctx into iv. That way encrypt()/decrypt() can
deliver 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|  131 +++---
 crypto/testmgr.h |3 +-
 drivers/net/Kconfig  |1 -
 drivers/net/wireless/hostap/Kconfig  |2 -
 drivers/net/wireless/ipw2x00/Kconfig |2 -
 include/crypto/arc4.h|   26 +++
 net/mac80211/Kconfig |1 -
 net/wireless/lib80211_crypt_tkip.c   |   10 ++-
 9 files changed, 123 insertions(+), 55 deletions(-)
 create mode 100644 include/crypto/arc4.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 81c185a..5fab1c3 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -561,7 +561,7 @@ config CRYPTO_ANUBIS
 
 config CRYPTO_ARC4
tristate ARC4 cipher algorithm
-   select CRYPTO_ALGAPI
+   select CRYPTO_BLKCIPHER
help
  ARC4 cipher algorithm.
 
diff --git a/crypto/arc4.c b/crypto/arc4.c
index 8be47e1..1b20463 100644
--- a/crypto/arc4.c
+++ b/crypto/arc4.c
@@ -1,4 +1,4 @@
-/* 
+/*
  * Cryptographic API
  *
  * ARC4 Cipher Algorithm
@@ -13,76 +13,122 @@
  */
 #include linux/module.h
 #include linux/init.h
-#include linux/crypto.h
+#include crypto/algapi.h
+#include crypto/arc4.h
 
 #define ARC4_MIN_KEY_SIZE  1
 #define ARC4_MAX_KEY_SIZE  256
 #define ARC4_BLOCK_SIZE1
 
-struct arc4_ctx {
-   u8 S[256];
-   u8 x, y;
-};
-
 static int arc4_set_key(struct crypto_tfm *tfm, const u8 *in_key,
unsigned int key_len)
 {
-   struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
+   /*
+* ARC4 is special: The user should supply an IV as struct arc4_iv and
+* fill either the key or the iv.
+*/
+   return -EOPNOTSUPP;
+}
+
+static void arc4_key_to_iv(const u8 *in_key, u32 key_len, struct arc4_iv *iv)
+{
int i, j = 0, k = 0;
 
-   ctx-x = 1;
-   ctx-y = 0;
+   iv-iv.x = 1;
+   iv-iv.y = 0;
 
-   for(i = 0; i  256; i++)
-   ctx-S[i] = i;
+   for (i = 0; i  256; i++)
+   iv-iv.S[i] = i;
 
-   for(i = 0; i  256; i++)
+   for (i = 0; i  256; i++)
{
-   u8 a = ctx-S[i];
+   u8 a = iv-iv.S[i];
j = (j + in_key[k] + a)  0xff;
-   ctx-S[i] = ctx-S[j];
-   ctx-S[j] = a;
-   if(++k = key_len)
+   iv-iv.S[i] = iv-iv.S[j];
+   iv-iv.S[j] = a;
+   if (++k = key_len)
k = 0;
}
-
-   return 0;
 }
 
-static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+static void arc4_ivsetup(struct arc4_iv *iv)
 {
-   struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
+   struct arc4_iv tmp_iv;
 
-   u8 *const S = ctx-S;
-   u8 x = ctx-x;
-   u8 y = ctx-y;
-   u8 a, b;
+   if (iv-type == ARC4_TYPE_IV)
+   return;
 
-   a = S[x];
-   y = (y + a)  0xff;
-   b = S[y];
-   S[x] = b;
-   S[y] = a;
-   x = (x + 1)  0xff;
-   *out++ = *in ^ S[(a + b)  0xff];
+   memcpy(tmp_iv, iv, sizeof(tmp_iv));
+   arc4_key_to_iv(tmp_iv.key.key, tmp_iv.key.key_len, iv);
+   iv-type = ARC4_TYPE_IV;
+}
+
+static int arc4_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
+   struct scatterlist *src, unsigned int nbytes)
+{
+   struct blkcipher_walk walk;
+   struct arc4_iv *aiv;
+   u8 *S;
+   u8 x;
+   u8 y;
+   u8 a, b;
+   int ret;
+
+   blkcipher_walk_init(walk, dst, src, nbytes);
+   ret = blkcipher_walk_virt(desc, walk);
+   if (ret)
+   return ret;
+
+   aiv = (struct arc4_iv *)walk.iv;
+   arc4_ivsetup(aiv);
+
+   S = aiv-iv.S;
+   x = aiv-iv.x;
+   y = aiv-iv.y;
+
+   while (walk.nbytes) {
+   u8 *in = walk.src.virt.addr;
+   u8 *out

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* 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 -ivsize says.

 users that cannot supply their own IVs can then set the IV to zero.
which works fine with kzalloc()

 When you see the zero flag in the IV, you reinitialise the IV per
 the key.
Okay. When we have to re-key and the user calls setkey() without
re-allocating thr cipher then I would not notice this. So I need a
counter. And all this will make it work but I still think it is fishy.
Plus we waste 258bytes.

In fact for arc4 we could just drop the key altogether since it
plays no part after setting the initial state.
Since I'm not allowed to kfree() the ctx in encrypt() are you proposing
tfm-setup_iv(iv, key)? 

  salsa also does not stick to plan here. ctx-input[6-9] is initialized
  in encrypt() path. So two threads sharing a ctx are going to clobber
  their state.
 
 Salsa should also be fixed.
I saw that comming. And I complaind back then that the assembly code was
not pretty enough... and removing the assembly is probably not option :)

For Salsa on the other hand the key is rather useful since all
we need is a two-byte IV that's just a sequence number.
No it's 8 bytes. Berstein's U8TO32_LITTLE() is actually a cpu_to_be32().
Not sure if he knows it :)
However I'm not sure where you going with this. salsa is fine besides
the clobber thing, isn't it?

Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] to fix vmac test fails on s390

[Sebastian Andrzej Siewior]

* 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 m64   = UINT64_C(0x);  /* 64-bit mask   */
 const u64 mpoly = UINT64_C(0x1fff1fff);  /* Poly key mask */
+
+#define pe64_to_cpup le64_to_cpup /* Prefer little endian */

Does it mean that I can switch it to be64_to_cpup ?

@@ -575,6 +572,10 @@ static int vmac_final(struct shash_desc 
   u8 nonce[16] = {};
 
   mac = vmac(NULL, 0, nonce, NULL, ctx);
+
+  /* set output invariant considering endianness */
+  mac = le64_to_cpup(mac);
So this is the fix. It would look better if you would include this
swap into vmac() itself. I'm not sure but this is probably causing a
dereference which could be avoided.
sparse should catch conversion bugs like this one if you were using
types likes __be64.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* 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(tfm);
 +if (unlikely(!ctx-new_key))
 +return;
 +memcpy(iv, ctx-iv, sizeof(ctx-iv));
 +ctx-new_key = 0;

Sorry, but this doesn't work.

A ctx is supposed to be reentrant.  That is, while one thread
is working away with a given ctx I should be able to use that
same ctx in a different thread without them clobbering each
other.
I also destroy the user supplied IV. You don't care about that? :)
So I have to know that someone called setkey() on this ctx but I can't
leave hints.
salsa also does not stick to plan here. ctx-input[6-9] is initialized
in encrypt() path. So two threads sharing a ctx are going to clobber
their state.

What about a new api for the stream cipher? We would merge the ctx part
and the iv into one handle. So the user would call setup_iv() instead of
setkey(). The difference would be that I can access the iv from within
setkey(). And the algorithm can fully express himself since he is no
longer trapped in the wrong body :)

So that means (in general) you must not modify the ctx in any
function other than setkey.
That is hard because I have a new state after encryption which I am only
allowed to save in the iv. And the new state may be reset in setkey()
where I can't touch the iv.
salsa does not keep/update its state. So the input[6-9] problem could be
fixed. Who/where is it used anyway? I can't see any user besides the
possible once (i.e. dm-crypt/ipsec).

This also brings up the bigger question of how we transition to
this new arc4.  I don't think we need to maintain exactly the
same behaviour as the existing ecb(arc4).

So what we could do is simply add a new blkcipher arc4, alongside
the existing cipher arc4.  Then we can convert the existing users
across, and finally remove the old arc4.
This has worked out before, lets stick to this :)

Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* 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 body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* 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 else :)

+  return;
+  memcpy(iv, ctx-iv, sizeof(ctx-iv));
+  ctx-new_key = 0;
+}

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  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

the state has been moved from ctx into iv. That way encrypt()/decrypt() can
deliver the same result for a given IV. This patch makes the cipher work with
dm-crypt not that it is a good thing. However, the performance may have
improved :)
The name is still ecb(aes) but since this is provided 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 but would require another patch.

 crypto/Kconfig   |2 +-
 crypto/arc4.c|  120 --
 crypto/testmgr.h |3 +-
 drivers/net/Kconfig  |1 -
 drivers/net/wireless/hostap/Kconfig  |2 -
 drivers/net/wireless/ipw2x00/Kconfig |2 -
 net/mac80211/Kconfig |1 -
 7 files changed, 87 insertions(+), 44 deletions(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 81c185a..5fab1c3 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -561,7 +561,7 @@ config CRYPTO_ANUBIS
 
 config CRYPTO_ARC4
tristate ARC4 cipher algorithm
-   select CRYPTO_ALGAPI
+   select CRYPTO_BLKCIPHER
help
  ARC4 cipher algorithm.
 
diff --git a/crypto/arc4.c b/crypto/arc4.c
index 8be47e1..b67b656 100644
--- a/crypto/arc4.c
+++ b/crypto/arc4.c
@@ -1,4 +1,4 @@
-/* 
+/*
  * Cryptographic API
  *
  * ARC4 Cipher Algorithm
@@ -13,76 +13,124 @@
  */
 #include linux/module.h
 #include linux/init.h
-#include linux/crypto.h
+#include crypto/algapi.h
 
 #define ARC4_MIN_KEY_SIZE  1
 #define ARC4_MAX_KEY_SIZE  256
 #define ARC4_BLOCK_SIZE1
 
-struct arc4_ctx {
+struct arc4_iv {
u8 S[256];
u8 x, y;
 };
 
+struct arc4_ctx {
+   struct arc4_iv iv;
+   u8 new_key;
+};
+
 static int arc4_set_key(struct crypto_tfm *tfm, const u8 *in_key,
unsigned int key_len)
 {
struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
int i, j = 0, k = 0;
 
-   ctx-x = 1;
-   ctx-y = 0;
+   ctx-iv.x = 1;
+   ctx-iv.y = 0;
 
-   for(i = 0; i  256; i++)
-   ctx-S[i] = i;
+   for (i = 0; i  256; i++)
+   ctx-iv.S[i] = i;
 
-   for(i = 0; i  256; i++)
+   for (i = 0; i  256; i++)
{
-   u8 a = ctx-S[i];
+   u8 a = ctx-iv.S[i];
j = (j + in_key[k] + a)  0xff;
-   ctx-S[i] = ctx-S[j];
-   ctx-S[j] = a;
-   if(++k = key_len)
+   ctx-iv.S[i] = ctx-iv.S[j];
+   ctx-iv.S[j] = a;
+   if (++k = key_len)
k = 0;
}
-
+   ctx-new_key = 1;
return 0;
 }
 
-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(tfm);
+   if (unlikely(!ctx-new_key))
+   return;
+   memcpy(iv, ctx-iv, sizeof(ctx-iv));
+   ctx-new_key = 0;
+}
 
-   u8 *const S = ctx-S;
-   u8 x = ctx-x;
-   u8 y = ctx-y;
+static int arc4_crypt(struct blkcipher_desc *desc, struct scatterlist *dst,
+   struct scatterlist *src, unsigned int nbytes)
+{
+   struct blkcipher_walk walk;
+   struct crypto_blkcipher *tfm = desc-tfm;
+   struct arc4_ctx *ctx = crypto_blkcipher_ctx(tfm);
+   struct arc4_iv *iv;
+   u8 *S;
+   u8 x;
+   u8 y;
u8 a, b;
+   int ret;
+
+   blkcipher_walk_init(walk, dst, src, nbytes);
+   ret = blkcipher_walk_virt(desc, walk);
+   if (ret)
+   return ret;
+
+   arc4_ivsetup(ctx, walk.iv);
+
+   iv = (struct arc4_iv *)walk.iv;
+
+   S = iv-S;
+   x = iv-x;
+   y = iv-y;
+
+   while (walk.nbytes) {
+   u8 *in = walk.src.virt.addr;
+   u8 *out = walk.dst.virt.addr;
+   u32 i;
+
+   for (i = 0; i  walk.nbytes; i++) {
+   a = S[x];
+   y = (y + a)  0xff;
+   b = S[y];
+   S[x] = b;
+   S[y] = a;
+   x = (x + 1)  0xff;
+   *out = *in ^ S[(a + b)  0xff];
+
+   in++;
+   out++;
+   }
+   ret = blkcipher_walk_done(desc, walk, 0);
+   WARN_ON(ret  0);
+   }
 
-   a = S[x];
-   y = (y + a)  0xff;
-   b = S[y];
-   S[x] = b;
-   S[y] = a;
-   x = (x + 1)  0xff;
-   *out++ = *in ^ S[(a + b)  0xff];
-
-   ctx-x = x;
-   ctx-y = y;
+   iv-x = x;
+   iv-y = y;
+   return ret;
 }
 
 static struct crypto_alg arc4_alg = {
-   .cra_name   =   arc4,
-   .cra_flags  =   CRYPTO_ALG_TYPE_CIPHER

Re: [PATCH] crypto/arc4: convert this stream cipher into a block cipher

[Sebastian Andrzej Siewior]

* 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 in there. I did not mix it up in the
patch :)


-Adrian

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] CRYPTO: Fix checkpatch errors warnings in arc4.c

[Sebastian Andrzej Siewior]

* 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 and a few others while re-writting it
yesterday. So I've taken care of this allready.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dm-crypt: disable block encryption with arc4

[Sebastian Andrzej Siewior]

* 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 haven't got around to doing it yet.

As to blacklisting algorithms not suitable for disk encryption,
that is up to the dm-crypt maintainers to decide.

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
seprate interface to grab a block cipher _or_ a stream cipher. So
something like this wouldn't happen. This is basically the check for
stream cipher without encrypt = decrypt plus with a struct the cra_u
union.
I can't imaging how you want to fix arc4 that it will work in dm-crypt.
The algorithm relies more or less on the fact that it envolves itself
during processing of data.
Salsa works with dm-crypt because the internal state is taken from the
IV and is never written back. dm-crypt always encrypts/decrypts a 512
block in one go. Splitting it in two and requesting two 256 block
encryptions would work with _every_ other block cipher but break salsa.


Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dm-crypt: disable block encryption with arc4

[Sebastian Andrzej Siewior]

* 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 interface to grab a block cipher _or_ a stream cipher. So

Just because something isn't a stream cipher doesn't mean that
it is safe for disk encryption.  People simply shouldn't be using
random algorithms for disk encryption.

 I can't imaging how you want to fix arc4 that it will work in dm-crypt.

I thought I've explained this before.  Just turn it into a blkcipher
and add IV.
I beg your pardon. I probably mixed things up.

 The algorithm relies more or less on the fact that it envolves itself
 during processing of data.

This is no different to any stream cipher.
Sure. So we fix arc4 and don't play mother . Okay I will into this :)


Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: device driver for hardware encryption

[Sebastian Andrzej Siewior]

* 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] :libfpga:fpga_dma_open+0xa5/0xab
[  319.938941]  [a0eb67ea] :libfpga:fpga_dma_block_read+0x12b/0x167
[  319.938945]  [802461c5] autoremove_wake_function+0x0/0x2e
[  319.938954]  [a039a248] :dsi_aes:dsi_aes_crypt+0x1db/0x24b
[  319.938960]  [a03a832a] :cbc:crypto_cbc_encrypt+0xe6/0x138
[  319.938964]  [a039e043] :aes_generic:aes_encrypt+0x0/0x21
[  319.938980]  [a0384f6f] :crypto_blkcipher:async_encrypt+0x35/0x3a
That looks wrong from the implementation POV: If your FPGA is doing aes
in CBC mode you shouldn't hack it into aes_generic.c or cbc.c but
implement your own driver with a higher priority.

I think it is happed when calling the
wait_event_interruptible(fdev-wait) routine, but i don't know how to
fix it. Hope can get you help. Thanks!

The encryption calling tree and irq handler tree showed in bellow

/* ecryption callint tree */
aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
|--dsi_aes_crypt((unsigned int *)in, (unsigned int *) out);
   |--do_crypt
  |--down_interruptible(fpga-sem)
   fpga_dma_block_write()
   |-- fpga_dma_block_transfer(base, pcie_addr, local_addr,
size, flag | FPGA_DMA_READ_FLAG); /*write data to hardware */
|--wait_event_interruptible(fdev-wait) /* waiting event*/
  up()

This isn't helping. Please look at a few drivers which use DMA to
transfer the data and use hardware encryption. Examples are:
- drivers/crypto/talitos.c
- drivers/crypto/hifn_795x.c

Best Regards

Bai Shuwei

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dm-crypt: disable block encryption with arc4

[Sebastian Andrzej Siewior]

* 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 doesn't 
currently work with dm-crypt, because it doesn't accept ecb(), cbc(), 
etc. chaining modes --- but if you remove the chaining mode manually, it 
works).

You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
cipher can't be used to encrypt disks.

Just because it will work does not make it a good idea.

SALSA20 is a stream cipher not a block cipher.
Block ciphers are used to encrypt data.
Stream ciphers are used to create one time pads, a set of encryption
keys, ...
There are block modes like CTR which can turn a block cipher into a
stream cipher. Those should not be used for disk encryption as well.


Mikulas

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  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] crypto/s390_aes: access .cip instead of .blk in cipher mode

[Sebastian Andrzej Siewior]

From aff6860829e06f8f7ba5f4a8160a6612e1a6eca7 Mon Sep 17 00:00:00 2001
From: Roel Kluin roel.kl...@gmail.com
Date: Thu, 7 Jan 2010 21:55:50 +0100

The fallback code in cipher mode touch the union fallback.blk instead
of fallback.cip. This is wrong because we use the cipher and not the
blockcipher. 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 sebast...@breakpoint.cc
---
 arch/s390/crypto/aes_s390.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
index 6be4503..58f4673 100644
--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -78,14 +78,14 @@ static int setkey_fallback_cip(struct crypto_tfm *tfm, 
const u8 *in_key,
struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
int ret;
 
-   sctx-fallback.blk-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
-   sctx-fallback.blk-base.crt_flags |= (tfm-crt_flags 
+   sctx-fallback.cip-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
+   sctx-fallback.cip-base.crt_flags |= (tfm-crt_flags 
CRYPTO_TFM_REQ_MASK);
 
ret = crypto_cipher_setkey(sctx-fallback.cip, in_key, key_len);
if (ret) {
tfm-crt_flags = ~CRYPTO_TFM_RES_MASK;
-   tfm-crt_flags |= (sctx-fallback.blk-base.crt_flags 
+   tfm-crt_flags |= (sctx-fallback.cip-base.crt_flags 
CRYPTO_TFM_RES_MASK);
}
return ret;
-- 
1.6.6

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

[PATCH 2/2] crypto/geode_aes: access .cip instead of .blk in cipher mode

[Sebastian Andrzej Siewior]

From caa5c9a662be92aa79b2ef1d14a509391cfa9254 Mon Sep 17 00:00:00 2001
From: Roel Kluin roel.kl...@gmail.com
Date: Thu, 7 Jan 2010 22:00:26 +0100

The fallback code in cipher mode touch the union fallback.blk instead
of fallback.cip. This is wrong because we use the cipher and not the
blockcipher. 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
---
 drivers/crypto/geode-aes.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 4801162..03e71b1 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -135,8 +135,8 @@ static int geode_setkey_cip(struct crypto_tfm *tfm, const 
u8 *key,
/*
 * The requested key size is not supported by HW, do a fallback
 */
-   op-fallback.blk-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
-   op-fallback.blk-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);
+   op-fallback.cip-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
+   op-fallback.cip-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);
 
ret = crypto_cipher_setkey(op-fallback.cip, key, len);
if (ret) {
@@ -263,7 +263,7 @@ static int fallback_init_cip(struct crypto_tfm *tfm)
 
if (IS_ERR(op-fallback.cip)) {
printk(KERN_ERR Error allocating fallback algo %s\n, name);
-   return PTR_ERR(op-fallback.blk);
+   return PTR_ERR(op-fallback.cip);
}
 
return 0;
-- 
1.6.6

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

Re: [PATCH] geode: PTR_ERR return of wrong pointer in fallback_init_cip()

[Sebastian Andrzej Siewior]

* 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 in
Linus' tree as b59cdcb33 ([S390] crypto: use more descriptive function
names for init/exit routines.) and I don't see this in the cryptodev or
crypto tree.
Herbert, do you want me to rebase this patch on top of Linus' tree or
do you have allready plans for this?

[0] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg03919.html

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] geode: PTR_ERR return of wrong pointer in fallback_init_cip()

[Sebastian Andrzej Siewior]

* 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
index 4801162..12cf864 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -263,7 +263,7 @@ static int fallback_init_cip(struct crypto_tfm *tfm)
 
   if (IS_ERR(op-fallback.cip)) {
   printk(KERN_ERR Error allocating fallback algo %s\n, name);
-  return PTR_ERR(op-fallback.blk);
+  return PTR_ERR(op-fallback.cip);
   }

This is correct however you missed one spot a few lines above that one.
Sergey Mironov sent a patch a while ago unfortunatelly a mangled one and
he hasn't resent it yet.
Could you please look at [0] for the missing spot? If you had fun fixing
that one, I've a made a similar mistake in s390's driver [1]. If not
please say so.

 
   return 0;

[0] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg03883.html
[1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg03888.html

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  http://vger.kernel.org/majordomo-info.html

Re: Bug in geode-aes.c ?

[Sebastian Andrzej Siewior]

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 fallback.cip. This is wrong because we use the cipher and not the
|blockcipher. This did not show any side effects yet because both types /
|structs contain the same element right now.

Signed-off-by: Sergey Mironov ier...@gmail.com

Looks good.

---
 arch/s390/crypto/aes_s390.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
index e33f32b..6f0f8b9 100644
--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -75,14 +75,14 @@ static int setkey_fallback_cip(struct crypto_tfm
*tfm, const u8 *in_key,
   struct s390_aes_ctx *sctx = crypto_tfm_ctx(tfm);
   int ret;

-  sctx-fallback.blk-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
-  sctx-fallback.blk-base.crt_flags |= (tfm-crt_flags 
+  sctx-fallback.cip-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
+  sctx-fallback.cip-base.crt_flags |= (tfm-crt_flags 
   CRYPTO_TFM_REQ_MASK);

   ret = crypto_cipher_setkey(sctx-fallback.cip, in_key, key_len);
   if (ret) {
   tfm-crt_flags = ~CRYPTO_TFM_RES_MASK;
-  tfm-crt_flags |= (sctx-fallback.blk-base.crt_flags 
+  tfm-crt_flags |= (sctx-fallback.cip-base.crt_flags 
   CRYPTO_TFM_RES_MASK);
   }
   return ret;
@@ -170,7 +170,7 @@ static int fallback_init_cip(struct crypto_tfm *tfm)

   if (IS_ERR(sctx-fallback.cip)) {
   printk(KERN_ERR Error allocating fallback algo %s\n, name);
-  return PTR_ERR(sctx-fallback.blk);
+  return PTR_ERR(sctx-fallback.cip);
   }

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

Re: Bug in geode-aes.c ?

[Sebastian Andrzej Siewior]

* Sergey Mironov | 2009-11-12 11:36:42 [+0300]:

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


Signed-off-by: Sergey Mironov ier...@gmail.com
Acked-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/drivers/crypto/geode-aes.c
index 4801162..03e71b1 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -135,8 +135,8 @@ static int geode_setkey_cip(struct crypto_tfm
*tfm, const u8 *key,
   /*
* The requested key size is not supported by HW, do a fallback
*/
-  op-fallback.blk-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
-  op-fallback.blk-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);
+  op-fallback.cip-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
+  op-fallback.cip-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);

   ret = crypto_cipher_setkey(op-fallback.cip, key, len);
   if (ret) {
@@ -263,7 +263,7 @@ static int fallback_init_cip(struct crypto_tfm *tfm)

   if (IS_ERR(op-fallback.cip)) {
   printk(KERN_ERR Error allocating fallback algo %s\n, name);
-  return PTR_ERR(op-fallback.blk);
+  return PTR_ERR(op-fallback.cip);
   }

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

Re: Bug in geode-aes.c ?

[Sebastian Andrzej Siewior]

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 fallback mode

|The fallback code in cipher mode touch the union fallback.blk instead
|of fallback.cip. This is wrong because we use the cipher and not the
|blockcipher. This did not show any side effects yet because both types /
|structs contain the same element right now.


Signed-off-by: Sergey Mironov ier...@gmail.com
---
 drivers/crypto/geode-aes.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 4801162..03e71b1 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -135,8 +135,8 @@ static int geode_setkey_cip(struct crypto_tfm
*tfm, const u8 *key,
   /*
* The requested key size is not supported by HW, do a fallback
*/
-  op-fallback.blk-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
-  op-fallback.blk-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);
+  op-fallback.cip-base.crt_flags = ~CRYPTO_TFM_REQ_MASK;
+  op-fallback.cip-base.crt_flags |= (tfm-crt_flags  
CRYPTO_TFM_REQ_MASK);

   ret = crypto_cipher_setkey(op-fallback.cip, key, len);
   if (ret) {
@@ -263,7 +263,7 @@ static int fallback_init_cip(struct crypto_tfm *tfm)

   if (IS_ERR(op-fallback.cip)) {
   printk(KERN_ERR Error allocating fallback algo %s\n, name);
-  return PTR_ERR(op-fallback.blk);
+  return PTR_ERR(op-fallback.cip);
   }

   return 0;

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  http://vger.kernel.org/majordomo-info.html

Re: Bug in geode-aes.c ?

[Sebastian Andrzej Siewior]

* 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 = ~CRYPTO_TFM_REQ_MASK;
 139 op-fallback.blk-base.crt_flags |= (tfm-crt_flags 
CRYPTO_TFM_REQ_MASK);

...

 144 tfm-crt_flags |=
(op-fallback.blk-base.crt_flags  CRYPTO_TFM_RES_MASK);
 145 }
 146 return ret;

Yup, good catch. It has to be cip instead of blk. I've copy/pasted it
and the same bug is in s390's crypto driver. No one noticed it because
both structs are equal, just the name / type is different.
Do you mind sending a patch?

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  http://vger.kernel.org/majordomo-info.html

Re: [QUESTION] blkcipher_walk_phys and memory

[Sebastian Andrzej Siewior]

* ?? ??? | 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 CRYPTO_ALG_TYPE_ABLKCIPHER. The
difference is that you could enqueue multiple transfers on the HW and
receive an interrupt once it is done.

I decided to use blkcipher_walk_phys() and blkcipher_walk_done()
functions. These functions take scatterlist and return one or more
struct page's and offsets. Then i pass those to dma_map_page() which
returns  dma_addr_t  to send to my device's DMA engine.
Everything seems to work (on ARM) but i have several questions:

1. Is it generally correct to do this? (see *_encrypt() handler below)
See comment below

2. Article at http://linux-mm.org/DeviceDriverMmap
says You may be tempted to call virt_to_page(addr) to get a struct
page pointer for a kmalloced address, but this is a violation of the
abstraction: kmalloc does not return pages, it returns another type of
memory object.
And blkcipher_walk_init() internally calls virt_to_page() on a pointer
It does not:
|static inline void blkcipher_walk_init(struct blkcipher_walk *walk,
|   struct scatterlist *dst,
|   struct scatterlist *src,
|   unsigned int nbytes)
|{   
|walk-in.sg = src;  
|walk-out.sg = dst;
|walk-total = nbytes;
|}  

allocated from unknown location (for example, in tcrypt.c there is
statically allocated buffer, but it is just one case of many). Is it
correct and how to think about it?
virt_to_page() is safe as long as you don't have HIGHMEM support or you
receive memory from vmalloc(). The blkcipher uses scatterwalk_map() for
src/dst which in turn ends up in kmap() what ensures that virt_to_page()
works on that page. In case it was a HIGHMEM page, it will be copied
into kernel address range and on unmap it will be copied back. And here
is some overhead: your HW should be able to access the HIGHMEM page
directly.

static int mcrypto_3des_ecb_encrypt(struct blkcipher_desc *desc,
struct scatterlist *dst, struct scatterlist *src, unsigned int nbytes)
{
struct mcrypto_device *device = g_mcrypto_device;
struct mcrypto_3des_ctx *ctx = crypto_blkcipher_ctx(desc-tfm);
struct blkcipher_walk walk;
int err;

blkcipher_walk_init(walk, dst, src, nbytes);
err = blkcipher_walk_phys(desc, walk);
ctx-mode = mcrypto_encrypt;

while((nbytes = walk.nbytes)) {
dma_addr_t src_dma, dst_dma;
size_t size = nbytes - (nbytes % DES3_EDE_MIN_BLOCK_SIZE);

src_dma = dma_map_page(device-dev, walk.src.phys.page,
walk.src.phys.offset, size, DMA_TO_DEVICE);
dst_dma = dma_map_page(device-dev, walk.dst.phys.page,
walk.dst.phys.offset, size, DMA_FROM_DEVICE);

It might happen that walk.src.phys.page == walk.dst.phys.page. In that
case you should use DMA_BIDIRECTIONAL


/* Performs actual DMA transfers and waits for completion */
mcrypto_3des_dmacrypt(device, ctx, src_dma, dst_dma, size);

dma_unmap_page(device-dev, dst_dma, size, DMA_FROM_DEVICE);
dma_unmap_page(device-dev, src_dma, size, DMA_TO_DEVICE);

err = blkcipher_walk_done(desc, walk, nbytes-size);
}
return err;
}

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  http://vger.kernel.org/majordomo-info.html

[PATCH] arm: new W macro to WORD_ACCESS

[Sebastian Andrzej Siewior]

As reported by Frans Pop the new global macro W on ARM which is included
via
|arch/arm/include/asm/uaccess.h:20
|include/linux/uaccess.h:5
|include/linux/crypto.h:26
|crypto/cast6.c:23

leads to a build error because the crypto/cast6.c defines a function
which is named W.

Reported-by: Frans Pop 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 the macro in this
commit and everything else I found due to compile error. Hope the new
name is acceptable. I think W in global name space is a bad thing to do.
In crypto there are many one letter identifier.
Since you use this in assembly code only you might want to move it to
another header file which does get included from every .c file.

 arch/arm/boot/compressed/head.S |   96 +++---
 arch/arm/include/asm/unified.h  |4 +-
 arch/arm/kernel/entry-armv.S|   50 ++--
 arch/arm/lib/copy_from_user.S   |2 +-
 arch/arm/lib/copy_template.S|4 +-
 arch/arm/lib/copy_to_user.S |2 +-
 arch/arm/lib/memcpy.S   |4 +-
 arch/arm/lib/memmove.S  |   28 ++--
 8 files changed, 95 insertions(+), 95 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fa6fbf4..6939dd0 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -612,8 +612,8 @@ call_cache_fn:  adr r12, proc_types
 proc_types:
.word   0x41560600  @ ARM6/610
.word   0xffe0
-   W(b)__arm6_mmu_cache_off@ works, but slow
-   W(b)__arm6_mmu_cache_off
+   WORD_ACCESS(b)  __arm6_mmu_cache_off@ works, but slow
+   WORD_ACCESS(b)  __arm6_mmu_cache_off
mov pc, lr
  THUMB(nop )
 @  b   __arm6_mmu_cache_on @ untested
@@ -631,29 +631,29 @@ proc_types:
 
.word   0x41007000  @ ARM7/710
.word   0xfff8fe00
-   W(b)__arm7_mmu_cache_off
-   W(b)__arm7_mmu_cache_off
+   WORD_ACCESS(b)  __arm7_mmu_cache_off
+   WORD_ACCESS(b)  __arm7_mmu_cache_off
mov pc, lr
  THUMB(nop )
 
.word   0x41807200  @ ARM720T (writethrough)
.word   0xff00
-   W(b)__armv4_mmu_cache_on
-   W(b)__armv4_mmu_cache_off
+   WORD_ACCESS(b)  __armv4_mmu_cache_on
+   WORD_ACCESS(b)  __armv4_mmu_cache_off
mov pc, lr
  THUMB(nop )
 
.word   0x41007400  @ ARM74x
.word   0xff00ff00
-   W(b)__armv3_mpu_cache_on
-   W(b)__armv3_mpu_cache_off
-   W(b)__armv3_mpu_cache_flush
+   WORD_ACCESS(b)  __armv3_mpu_cache_on
+   WORD_ACCESS(b)  __armv3_mpu_cache_off
+   WORD_ACCESS(b)  __armv3_mpu_cache_flush

.word   0x41009400  @ ARM94x
.word   0xff00ff00
-   W(b)__armv4_mpu_cache_on
-   W(b)__armv4_mpu_cache_off
-   W(b)__armv4_mpu_cache_flush
+   WORD_ACCESS(b)  __armv4_mpu_cache_on
+   WORD_ACCESS(b)  __armv4_mpu_cache_off
+   WORD_ACCESS(b)  __armv4_mpu_cache_flush
 
.word   0x7000  @ ARM7 IDs
.word   0xf000
@@ -668,39 +668,39 @@ proc_types:
 
.word   0x4401a100  @ sa110 / sa1100
.word   0xffe0
-   W(b)__armv4_mmu_cache_on
-   W(b)__armv4_mmu_cache_off
-   W(b)__armv4_mmu_cache_flush
+   WORD_ACCESS(b)  __armv4_mmu_cache_on
+   WORD_ACCESS(b)  __armv4_mmu_cache_off
+   WORD_ACCESS(b)  __armv4_mmu_cache_flush
 
.word   0x6901b110  @ sa1110
.word   0xfff0
-   W(b)__armv4_mmu_cache_on
-   W(b)__armv4_mmu_cache_off
-   W(b)__armv4_mmu_cache_flush
+   WORD_ACCESS(b)  __armv4_mmu_cache_on
+   WORD_ACCESS(b)  __armv4_mmu_cache_off
+   WORD_ACCESS(b)  __armv4_mmu_cache_flush
 
.word   0x56056930
.word   0xff00  @ PXA935
-   W(b)__armv4_mmu_cache_on
-   W(b)__armv4_mmu_cache_off
-   W(b)__armv4_mmu_cache_flush
+   WORD_ACCESS(b)  __armv4_mmu_cache_on

Re: [PATCH]: fix repetition test for hardware RNG to be FIPS compliant (v2)

[Sebastian Andrzej Siewior]

* 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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: fix repetition test for hardware RNG to be FIPS compliant

[Sebastian Andrzej Siewior]

* 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.
  *
  **/
+#define EXTRACT_SIZE 10
+#define REP_CHECK_BLOCK_COPIED 1
+struct repetition_check {
+  __u8 last_data[EXTRACT_SIZE];
+  __u8 flags;
+};
This struct should have 11 bytes and is only used in FIPS enabled mode.

 struct entropy_store;
 struct entropy_store {
@@ -414,7 +420,7 @@ struct entropy_store {
   unsigned add_ptr;
   int entropy_count;
   int input_rotate;
-  __u8 *last_data;
+  struct repetition_check *rep;
 };
so just a pointer to 11 bytes

 static __u32 input_pool_data[INPUT_POOL_WORDS];
@@ -714,7 +720,6 @@ void ad
 
-#define EXTRACT_SIZE 10
 
 /*
  *
@@ -856,18 +861,24 @@ static ssize_t extract_entropy(struct entropy_store *r, 
void *buf,
   __u8 tmp[EXTRACT_SIZE];
   unsigned long flags;
 
+repeat_extract:
   xfer_secondary_pool(r, nbytes);
   nbytes = account(r, nbytes, min, reserved);
 
   while (nbytes) {
   extract_buf(r, tmp);
 
-  if (r-last_data) {
+  if (r-rep) {
   spin_lock_irqsave(r-lock, flags);
-  if (!memcmp(tmp, r-last_data, EXTRACT_SIZE))
+  if ((r-rep-flags  REP_CHECK_BLOCK_COPIED) 
+  !memcmp(tmp, r-rep-last_data, EXTRACT_SIZE))
   panic(Hardware RNG duplicated output!\n);
-  memcpy(r-last_data, tmp, EXTRACT_SIZE);
+  memcpy(r-rep-last_data, tmp, EXTRACT_SIZE);
   spin_unlock_irqrestore(r-lock, flags);
+  if (!(r-rep-flags  REP_CHECK_BLOCK_COPIED)) {
+  r-rep-flags |= REP_CHECK_BLOCK_COPIED;
+  goto repeat_extract;
+  }
   }
   i = min_t(int, nbytes, EXTRACT_SIZE);
   memcpy(buf, tmp, i);
@@ -952,8 +963,10 @@ static void init_std_data(struct entropy_store *r)
   mix_pool_bytes(r, now, sizeof(now));
   mix_pool_bytes(r, utsname(), sizeof(*(utsname(;
   /* Enable continuous test in fips mode */
-  if (fips_enabled)
-  r-last_data = kmalloc(EXTRACT_SIZE, GFP_KERNEL);
+  if (fips_enabled) {
+  r-rep = kmalloc(sizeof(struct repetition_check), GFP_KERNEL);
and we alloc this 11 bytes via kmalloc. The smallest allocation is
afaik 32 bytes. The three pools (input_pool, blocking_pool,
nonblocking_pool) are in data seg so it probably does not hurt if you
add the extra 10 bytes there. The advantage:
- you don't have to deal with -ENOMEM. Otherwise it could be possible
  that you not doing anything special in fips_mode
- you go OOM if the user is using RNDCLEARPOOL ioctl(). Slowly but you
  do.

+  r-rep-flags = 0;
+  }
 }
 
 static int rand_initialize(void)

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  http://vger.kernel.org/majordomo-info.html

Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken

[Sebastian Andrzej Siewior]

* 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
|for dev in $rootdev $resumedevs; do
|   info=$(cryptsetup luksDump $rootdev)
|   if [ $? -ne 0]; then
|   # Partition is now encrypted
|   continue
|   fi
|   cipher=$(cryptsetup luksDump /dev/md1 |grep Cipher name: | \
|sed 's...@^cipher name:\s\+@@')
|   add_crypto_modules $cipher
|   mode=$(cryptsetup luksDump /dev/md1 |grep Cipher name:)
|   echo $mode | sed \
|   -e 's...@^cipher name:\s\+@@') \
|   -e 's...@-@ @' \
|   -e 's@:@ @'
|   # mode is now block_mode IV_mode hash
|   blk_mode=$(echo $mode | awk '{print $1}'
|   hash=$(echo $mode | awk '{print $3})'
|   add_crypto_modules $blk_mode
|   add_crypto_modules $hash
|done   
instead of hardcoding cbc, aes  sha256

 So this brings me to the following question: Why are you so picky and you
 don't take all of the modules? sh 2.6.30-1 on various debian archs:
 du -sh  x86_64  i386  powerpc  s390x   mips(r5k-ip32)
 crypto  720K636K  1.1M 804K968K
 arch/arch/crypto  72K 36K   092K 0
 driver/crypto   32K 60K   60K  0   52K
 Total   824K732K  1.2M 896K1020
 
 So all modules together have an average footprint of 941.0K. This isn't
 that much. There is no size limit on initrd unless you are on a system
 with has 32MiB or something like that :)
 With *all* those crypto modules which are selected and built you are
 able to cover all corner cases.
 I took a look at hooks/cryptroot and really and only a few modules are
 included. Right now you don't include HW cipher e.g. VIA's padlock or
 AMD's geode. If you don't load those module while openning the root
 partition (the first request), then the module is never loaded / used.
 The other unhandled case are non default ciphers like xts(aes) which one
 might use. The brand new aes implementation aesni-intel is also not be
 considered. Most modules have _generic in their name if there is
 another implementation available and name-arch if there is an assembly
 variant but I would prefer that this does not become part of an ABI
 where one can rely on.
 
 Would it be okay for you to change the way the crypto modules are picked
 and include the full set?

i don't like the idea to add _all_ crypto modules into the initramfs per
default. the size of crypto and arch/arch/crypto will keep on growing
for kernels which do have ship all available modules for ciphers and
implementations. i think that the initramfs should be a _minimal_
system, and detecting the required crypto modules should be possible.
Why is a minimal initramsfs here a good thing here? 1 MiB isn't that
huge and with gzip it does not grow much. Here is an example on my amd64
with current initramfs as of 2.6.30-1-amd64:
picky   : 10511917 bytes / 11 MiB
full crypto : 10729154 bytes / 11 MiB / + 2.1%

So. On AMD64 we are talking here about 200KiB or 2% of the whole image
size.
If arch/*/crypto grows than just because there is more support and this
is a good thing not bad.

alternative crypto cipher and blockcipher modules are already detected
if required, as information about these are available from the cryptroot
configuration (either luks header or cmdline options given to cryptsetup).
ah so my little script was not required. What about d-i? AFAIK that one
runs from initramfs and relies on modules which are selected here. Isn't
this the case?

i added cryptomgr, chainiv and krng to the list of required modules in
/usr/share/initramfs-tools/hooks/cryptroot for now.
And in .32 you have work again because you need eseqiv.

still i see the point that this solution has it's drawbacks. modules for
crypto hardware and cipher implementations not following the convention to
call modules cipher_generic and cipher-alias aren't detected by the
current system.
exactly. Plus runtime dependency.

i guess the best solution would be to improve the module dependency
system. cipher meta-modules like 'aes' should depend on all available
implementations. same for ivciphers, hashs, rng implementations etc.

what do you think about it?
I don't the like extra work for 2%. Even if someone does this, you still
have lets say the geode, via-padlock and the hfin driver on a 486 system
which can't use all of them and relies on pure SW. No benefit there.

Okay. You put the crypto modules in initramfs in case the root partition
and or swap is encrypted. In case just /data is encrypted you don't need
those modules at all. So d-i needs all them in case the user might want
to xts(twofish) and not just the standard thing. The user-initramfs
script could take the full set of crypto 

Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken

[Sebastian Andrzej Siewior]

* 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 be related to the kernel config in some way.
It must be the kernel confing since I run .30.stable and it works. I try
to look at it later.

Your kernel config is fine, the problem is that the initramfs tools do
not copy all of the required modules into the initramfs. The missing
modles are:
- cryptomgr: that one is responsible to load the cbc and aes module and
  bind them to cbc(aes)
- chainiv: that one creates IVs if the user does not specify one.
  dm-crypt probably does not use that one but is required due to the way
  crypto works atm.
- krng: provides random numbers and is required by chainiv.

If you add those three to /etc/initramfs/modules than it should work.

Could someone please look at initramfs to figure out why those three
modules are not copied in this reduced setup?

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  http://vger.kernel.org/majordomo-info.html

Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken

[Sebastian Andrzej Siewior]

* 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 installation, but even after I enable
   virtually everything in the crypto section of the kernel configs, cbc
   fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
   crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
   sha256_generic), but even after modprobing / insmoding
   everything, /proc/crypto shows that aes and sha is there, but not cbc.
   
   The problem has been reproduced (using my kernel config) by Jonas
   Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
   We've tried numerous different kernel versions in the .30 / .31 range.
   
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
   
   Does this mean that something else somewhere in the kernel needs to be
   configured but isn't, and the necessary dependency isn't properly
   declared?
   
   My config is at:
   http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835
   
   [I'm not subscribed to lkml; please cc me on responses]
 the problem rather is that loading the cbc blockcipher module simply
 does nothing. the module is listed in /proc/modules, but the blockcipher
 is still missing from /proc/crypto.
Yes. cbc(aes) is auto-generated once someone requests such a cipher. The
block modes are not listed.

 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 be related to the kernel config in some way.
It must be the kernel confing since I run .30.stable and it works. I try
to look at it later.

---
~Randy

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  http://vger.kernel.org/majordomo-info.html

[PATCH v4] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

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...@breakpoint.cc
---
v3..v4: change Kconfig help text  added Nicolas' ack.

 drivers/crypto/Kconfig   |   13 +
 drivers/crypto/Makefile  |1 +
 drivers/crypto/mv_cesa.c |  606 ++
 drivers/crypto/mv_cesa.h |  119 +
 4 files changed, 739 insertions(+), 0 deletions(-)
 create mode 100644 drivers/crypto/mv_cesa.c
 create mode 100644 drivers/crypto/mv_cesa.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 5b27692..efc9484 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -157,6 +157,19 @@ config S390_PRNG
  ANSI X9.17 standard. The PRNG is usable via the char device
  /dev/prandom.
 
+config CRYPTO_DEV_MV_CESA
+   tristate Marvell's Cryptographic Engine
+   depends on PLAT_ORION
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES
+   select CRYPTO_BLKCIPHER2
+   help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Marvell Orion
+ and Kirkwood SoCs, such as QNAP's TS-209.
+
+ Currently the driver supports AES in ECB and CBC mode without DMA.
+
 config CRYPTO_DEV_HIFN_795X
tristate Driver HIFN 795x crypto accelerator chips
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 9bf4a2b..6ffcb3f 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
new file mode 100644
index 000..f28502c
--- /dev/null
+++ b/drivers/crypto/mv_cesa.c
@@ -0,0 +1,606 @@
+/*
+ * Support for Marvell's crypto engine which can be found on some Orion5X
+ * boards.
+ *
+ * Author: Sebastian Andrzej Siewior  sebastian at breakpoint dot cc 
+ * License: GPLv2
+ *
+ */
+#include crypto/aes.h
+#include crypto/algapi.h
+#include linux/crypto.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+
+#include mv_cesa.h
+/*
+ * STM:
+ *   /---\
+ *   |  | request complete
+ *  \./ |
+ * IDLE - new request - BUSY - done - DEQUEUE
+ * /??\   |
+ * || more scatter entries
+ * \/
+ */
+enum engine_status {
+   ENGINE_IDLE,
+   ENGINE_BUSY,
+   ENGINE_W_DEQUEUE,
+};
+
+/**
+ * struct req_progress - used for every crypt request
+ * @src_sg_it: sg iterator for src
+ * @dst_sg_it: sg iterator for dst
+ * @sg_src_left:   bytes left in src to process (scatter list)
+ * @src_start: offset to add to src start position (scatter list)
+ * @crypt_len: length of current crypt process
+ * @sg_dst_left:   bytes left dst to process in this scatter list
+ * @dst_start: offset to add to dst start position (scatter list)
+ * @total_req_bytes:   total number of bytes processed (request).
+ *
+ * sg helper are used to iterate over the scatterlist. Since the size of the
+ * SRAM may be less than the scatter size, this struct struct is used to keep
+ * track of progress within current scatterlist.
+ */
+struct req_progress {
+   struct sg_mapping_iter src_sg_it;
+   struct sg_mapping_iter dst_sg_it;
+
+   /* src mostly */
+   int sg_src_left;
+   int src_start;
+   int crypt_len;
+   /* dst mostly */
+   int sg_dst_left;
+   int dst_start;
+   int total_req_bytes;
+};
+
+struct crypto_priv {
+   void __iomem *reg;
+   void __iomem *sram;
+   int irq;
+   struct task_struct *queue_th;
+
+   /* the lock protects queue and eng_st */
+   spinlock_t lock;
+   struct crypto_queue queue;
+   enum engine_status eng_st;
+   struct ablkcipher_request *cur_req;
+   struct req_progress p;
+   int max_req_size;
+   int sram_size;
+};
+
+static struct crypto_priv *cpg;
+
+struct mv_ctx {
+   u8 aes_enc_key[AES_KEY_LEN];
+   u32 aes_dec_key[8];
+   int key_len;
+   u32 need_calc_aes_dkey;
+};
+
+enum crypto_op {
+   COP_AES_ECB,
+   COP_AES_CBC,
+};
+
+struct

Re: Padlock with VIA Nano still crashing

[Sebastian Andrzej Siewior]

* 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 please provide /proc/cpuinfo? What parameters have you used to
create to setup your crypt partition (key size, cipher mode)?

I've tested crypto dev recently with ipsec and that seemed to work.

 Regards,
 Nico

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  http://vger.kernel.org/majordomo-info.html

Re: [1/9] Convert padlock sha to shash

[Sebastian Andrzej Siewior]

* 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 top. I try that ip xfrm thing
later today.

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  http://vger.kernel.org/majordomo-info.html

Re: [1/9] Convert padlock sha to shash

[Sebastian Andrzej Siewior]

* 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 this patch applied too:

It passes the testmgr with that patch on top. I try that ip xfrm thing
later today.

Okay, Herbert it is working. I've setup a tunnel between two boxes and
was able to ping and copy stuff from /dev/zero on one box to /dev/null
on the other. 

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  http://vger.kernel.org/majordomo-info.html

Re: [1/9] Convert padlock sha to shash

[Sebastian Andrzej Siewior]

* 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
|0010: 99 f2 ad 73
|alg: hash: Chunking test 1 failed for sha256-padlock
|: 9e 49 25 fa b3 a8 45 de 53 e9 9f d0 e8 7d 2c 33
|0010: 09 51 6b 33 15 cb e0 4e 22 c0 04 1b 1e 25 ad c9
|padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

Do you think that it is something obvious or should I dig into it?

Cheers,

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  http://vger.kernel.org/majordomo-info.html

Re: [1/9] Convert padlock sha to shash

[Sebastian Andrzej Siewior]

* 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 a particular test case in mind or should I just grab
ipsec-tools, setup a tunnel and send a few packets?

Thanks,

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: Update stdrng test name so that the testmgr finds it properly

[Sebastian Andrzej Siewior]

* 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  0)
   goto notest;
 
-  if (fips_enabled  !alg_test_descs[i].fips_allowed)
+  if (fips_enabled  ((i = 0  !alg_test_descs[i].fips_allowed) ||
+   (j = 0  !alg_test_descs[j].fips_allowed)))
   goto non_fips_alg;
 
-  rc = alg_test_descs[i].test(alg_test_descs + i, driver,
-type, mask);
+  rc = 0;
+  if (i = 0)
+  rc |= alg_test_descs[i].test(alg_test_descs + i, driver,
+   type, mask);
+  if (j = 0)
+  rc |= alg_test_descs[j].test(alg_test_descs + j, driver,
+   type, mask);

Do you execute test2 if test1 failed on purpose?
If not what about:

if (!rc  j = 0)
rc = alg_test_descs[j].test(alg_test_descs + j, driver,
 type, mask);

so there is return code mixup.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: Update stdrng test name so that the testmgr finds it properly

[Sebastian Andrzej Siewior]

* 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 keep this list sorted by algorithm name. */
 static const struct alg_test_desc alg_test_descs[] = {
  {
- .alg = ansi_cprng,
+ .alg = stdrng,
  .test = alg_test_cprng,
  .fips_allowed = 1,
  .suite = {

Don't you use this vector for _all_ stdrngs now? krng for instance will
fail.
This is wrong anyway because the alg field has to be sorted
alphabetically due to the nature of the search function.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto/ansi prng: alloc cipher just in in init()

[Sebastian Andrzej Siewior]

* 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 guess.

Neil

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  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] crypto/ansi prng: alloc cipher just in in init()

[Sebastian Andrzej Siewior]

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 is turned off.
|Pid: 4926, comm: modprobe Tainted: G   M 2.6.31-rc1-22297-g5298976 #24
|Call Trace:
| [c011dd93] __might_sleep+0xf9/0x101
| [c0777aa0] down_read+0x16/0x68
| [c048bf04] crypto_alg_lookup+0x16/0x34
| [c048bf52] crypto_larval_lookup+0x30/0xf9
| [c048c038] crypto_alg_mod_lookup+0x1d/0x62
| [c048c13e] crypto_alloc_base+0x1e/0x64
| [c04bf991] reset_prng_context+0xab/0x13f
| [c04e5cfc] ? __spin_lock_init+0x27/0x51
| [c04bfce1] cprng_init+0x2a/0x42
| [c048bb4c] __crypto_alloc_tfm+0xfa/0x128
| [c048c153] crypto_alloc_base+0x33/0x64
| [c04933c9] alg_test_cprng+0x30/0x1f4
| [c0493329] alg_test+0x12f/0x19f
| [c0177f1f] ? __alloc_pages_nodemask+0x14d/0x481
| [d09219e2] do_test+0xf9d/0x163f [tcrypt]
| [d0920de6] do_test+0x3a1/0x163f [tcrypt]
| [d0926035] tcrypt_mod_init+0x35/0x7c [tcrypt]
| [c010113c] _stext+0x54/0x12c
| [d0926000] ? tcrypt_mod_init+0x0/0x7c [tcrypt]
| [c01398a3] ? up_read+0x16/0x2b
| [c0139fc4] ? __blocking_notifier_call_chain+0x40/0x4c
| [c014ee8d] sys_init_module+0xa9/0x1bf
| [c010292b] sysenter_do_call+0x12/0x32

because a spin lock is held and crypto_alloc_base() may sleep.
There is no reason to re-allocate the cipher, the state is resetted in
-setkey(). This move it to init.

Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 crypto/ansi_cprng.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index ff00b58..259d2de 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto/ansi_cprng.c
@@ -307,17 +307,6 @@ static int reset_prng_context(struct prng_context *ctx,
memset(ctx-rand_data, 0, DEFAULT_BLK_SZ);
memset(ctx-last_rand_data, 0, DEFAULT_BLK_SZ);
 
-   if (ctx-tfm)
-   crypto_free_cipher(ctx-tfm);
-
-   ctx-tfm = crypto_alloc_cipher(aes, 0, 0);
-   if (IS_ERR(ctx-tfm)) {
-   dbgprint(KERN_CRIT Failed to alloc tfm for context %p\n,
-   ctx);
-   ctx-tfm = NULL;
-   goto out;
-   }
-
ctx-rand_data_valid = DEFAULT_BLK_SZ;
 
ret = crypto_cipher_setkey(ctx-tfm, prng_key, klen);
@@ -342,6 +331,13 @@ static int cprng_init(struct crypto_tfm *tfm)
struct prng_context *ctx = crypto_tfm_ctx(tfm);
 
spin_lock_init(ctx-prng_lock);
+   ctx-tfm = crypto_alloc_cipher(aes, 0, 0);
+   if (IS_ERR(ctx-tfm)) {
+   dbgprint(KERN_CRIT Failed to alloc tfm for context %p\n,
+   ctx);
+   ctx-tfm = NULL;
+   return PTR_ERR(ctx-tfm);
+   }
 
if (reset_prng_context(ctx, NULL, DEFAULT_PRNG_KSZ, NULL, NULL)  0)
return -EINVAL;
-- 
1.6.3.3

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

Re: [RFC 1/7] crypto: Add GHASH digest algorithm for GCM

[Sebastian Andrzej Siewior]

* 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/hash.h
 Do you mind to sort them?

Sorry, can you tell me what is the better order?

For header files it shouldn't matter if you include linux/module.h
followed by linux/init.h or the other way around. If you have them in
one place and sorted you can easily find out where to put the next one
and tell whether a specific header file is allready included. You also
make it a little harder to include one header file twice. If you think
this does not happen, a quick grep over the scsi tree shows:

|$ fgrep -R '#include ' drivers/scsi/ | sort  sort.txt
|$ fgrep -R '#include ' drivers/scsi/ | sort -u  sort-u.txt
|$ diff -u sort.txt sort-u.txt
|--- sort.txt  2009-06-18 09:12:27.551876506 +0200
|+++ sort-u.txt  2009-06-18 09:12:36.226342283 +0200
|@@ -1347,7 +1347,6 @@
| drivers/scsi/fcoe/libfcoe.c:#include linux/list.h
| drivers/scsi/fcoe/libfcoe.c:#include linux/module.h
| drivers/scsi/fcoe/libfcoe.c:#include linux/netdevice.h
|-drivers/scsi/fcoe/libfcoe.c:#include linux/netdevice.h
| drivers/scsi/fcoe/libfcoe.c:#include linux/spinlock.h
| drivers/scsi/fcoe/libfcoe.c:#include linux/timer.h
| drivers/scsi/fcoe/libfcoe.c:#include linux/types.h
|@@ -1623,7 +1622,6 @@
| drivers/scsi/gdth.h:#include linux/types.h
| drivers/scsi/gdth_proc.c:#include linux/completion.h
| drivers/scsi/gvp11.c:#include gvp11.h
|-drivers/scsi/gvp11.c:#include gvp11.h
| drivers/scsi/gvp11.c:#include scsi.h
| drivers/scsi/gvp11.c:#include scsi_module.c
| drivers/scsi/gvp11.c:#include wd33c93.h
|@@ -1718,7 +1716,6 @@
| drivers/scsi/ibmvscsi/ibmvfc.h:#include linux/types.h
| drivers/scsi/ibmvscsi/ibmvscsi.c:#include ibmvscsi.h
| drivers/scsi/ibmvscsi/ibmvscsi.c:#include asm/firmware.h
|-drivers/scsi/ibmvscsi/ibmvscsi.c:#include asm/firmware.h
| drivers/scsi/ibmvscsi/ibmvscsi.c:#include asm/vio.h
| drivers/scsi/ibmvscsi/ibmvscsi.c:#include linux/delay.h
| drivers/scsi/ibmvscsi/ibmvscsi.c:#include linux/dma-mapping.h
|@@ -2633,7 +2630,6 @@
| drivers/scsi/mpt2sas/mpt2sas_transport.c:#include scsi/scsi_host.h
| drivers/scsi/mpt2sas/mpt2sas_transport.c:#include scsi/scsi_transport_sas.h
| drivers/scsi/mvme147.c:#include mvme147.h
|-drivers/scsi/mvme147.c:#include mvme147.h
| drivers/scsi/mvme147.c:#include scsi.h
| drivers/scsi/mvme147.c:#include scsi_module.c
| drivers/scsi/mvme147.c:#include wd33c93.h

SCSI was just a random example.

Best Regards,
Huang Ying

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm/orion5x: add sram support for crypto

[Sebastian Andrzej Siewior]

* 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.
 If you thing it is too early I can keep hacking in my own git tree until
 I get the dmac_flush_range() hack out or so.

I have no problem with you submitting it now.  It is not complete yet 
but what is there is plenty functional.  However I'd prefer if you used 
the API based on sg_copy_buffer() which includes a call to 
flush_kernel_dcache_page() already for mainline inclusion, so to have 
good style up front. ( a patch to fix flush_kernel_dcache_page() on ARM 
is already queued).
sg_copy_from_buffer() since the other one is static. I'm little unhappy
with it because this forces me to have the entire buffer ready. This
is not a problem for dm-crypt because I get just one scatterlist entry
with 512 bytes. I don't know about others but this will put a
limitation / break them.

It looks like sg_miter_start() which is exported doesn't provide the
the required flush interface. What about:

--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -259,12 +259,6 @@ static void dequeue_complete_req(void)
dst_copy = min(cpg-p.crypt_len, cpg-p.sg_dst_left);
 
memcpy(buf, cpg-sram + SRAM_DATA_OUT_START, dst_copy);
-   /*
-* XXX This is a temporary hack to flush data from cache back
-* into phys ram so user space sees correct data. This goes
-* away as soon as DMA support is added to this driver
-*/
-   dmac_flush_range(buf, buf + dst_copy);
 
cpg-p.sg_dst_left -= dst_copy;
cpg-p.crypt_len -= dst_copy;
@@ -309,7 +303,7 @@ static void mv_enqueue_new_req(struct ablkcipher_request 
*req)
sg_miter_start(cpg-p.src_sg_it, req-src, num_sgs, 0);
 
num_sgs = count_sgs(req-dst, req-nbytes);
-   sg_miter_start(cpg-p.dst_sg_it, req-dst, num_sgs, 0);
+   sg_miter_start(cpg-p.dst_sg_it, req-dst, num_sgs, 
SG_MITER_FLUSH_CACHE);
mv_process_current_q(1);
 }
 
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index e599698..8f98450 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -242,6 +242,7 @@ size_t sg_copy_to_buffer(struct scatterlist *sgl, unsigned 
int nents,
  */
 
 #define SG_MITER_ATOMIC(1  0) /* use kmap_atomic */
+#define SG_MITER_FLUSH_CACHE   (1  1) /* flash cache on unmap */
 
 struct sg_mapping_iter {
/* the following three fields can be accessed directly */
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index a295e40..4b07f7a 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -394,6 +394,9 @@ void sg_miter_stop(struct sg_mapping_iter *miter)
if (miter-addr) {
miter-__offset += miter-consumed;
 
+   if (miter-__flags  SG_MITER_FLUSH_CACHE)
+   flush_kernel_dcache_page(miter-page);
+
if (miter-__flags  SG_MITER_ATOMIC) {
WARN_ON(!irqs_disabled());
kunmap_atomic(miter-addr, KM_BIO_SRC_IRQ);
-- 
1.6.0.6




Nicolas

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  http://vger.kernel.org/majordomo-info.html

Re: [WIP] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

* 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 src_sg_it;
 +struct sg_mapping_iter dst_sg_it;
 +
 +/* src mostly */
 +int this_sg_b_left;
 +int src_start;
 +int crypt_len;
 +/* dst mostly */
 +int this_dst_sg_b_left;
 +int dst_start;
 +int total_req_bytes;
 +};

kerneldoc style documentation wouldn't go amiss here.
added

 +
 +static void reg_write(void __iomem *mem, u32 val)
 +{
 +__raw_writel(val, mem);
 +}
 +
 +static u32 reg_read(void __iomem *mem)
 +{
 +return __raw_readl(mem);
 +}

do you really need to wrapper these? 
Not really. Initially I planned to pass the device handle instead of the
memory pointer. Also using (addr, val) looks better than the other way
around.

it is also readl/writel for pointers obtained from ioremap()
correct. So I get rid of my wrapper and switch to readl/writel

 +
 +#if 0
 +static void hex_dump(unsigned char *info, unsigned char *buf, unsigned int 
 len)
 +{
 +printk(KERN_ERR %s\n, info);
 +print_hex_dump(KERN_ERR, , DUMP_PREFIX_OFFSET,
 +16, 1,
 +buf, len, false);
 +printk(KERN_CONT \n);
 +}
 +#endif

#if 0 considered bad.
I needed this a few times. Now I don't and its gone.

 +
 +static int m_probe(struct platform_device *pdev)
 +{
 +struct crypto_priv *cp;
 +struct resource *res;
 +int irq;
 +int ret;
 +
 +if (cpg) {
 +printk(KERN_ERR Second crypto dev?\n);
 +return -EBUSY;
 +}
 +
 +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, regs);
 +if (!res)
 +return -ENODEV;

Returning -ENODEV is considered harmful, it will not trigger any warning
from the driver core.
I switched to ENXIO because that fits better (No such device or address)
I thing. However this also doesn't trigger any warning from the core.
What do you suggest?


-- 
Ben

Thanks for the review Ben.

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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm/orion5x: add sram support for crypto

[Sebastian Andrzej Siewior]

* Nicolas Pitre | 2009-06-11 15:17:09 [-0400]:

This one is already merged in the Orion and ARM tree, with a minor fix 
and device renamed to be more generic.  The equivalent registration for 
Kirkwood is merged as well already.

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].
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 after adding sram mapping

Without incrementing the counter the next window setup will overwrite
the SRAM mapping.

Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 arch/arm/mach-orion5x/addr-map.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-orion5x/addr-map.c b/arch/arm/mach-orion5x/addr-map.c
index 6f3f77d..d78731e 100644
--- a/arch/arm/mach-orion5x/addr-map.c
+++ b/arch/arm/mach-orion5x/addr-map.c
@@ -200,6 +200,6 @@ void __init orion5x_setup_pcie_wa_win(u32 base, u32 size)
 
 int __init orion5x_setup_sram_win(void)
 {
-   return setup_cpu_win(win_alloc_count, ORION5X_SRAM_PHYS_BASE,
+   return setup_cpu_win(win_alloc_count++, ORION5X_SRAM_PHYS_BASE,
ORION5X_SRAM_SIZE, TARGET_SRAM, ATTR_SRAM, -1);
 }
-- 
1.6.0.6

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

[PATCH] arm/orion5x: init the crypto device

[Sebastian Andrzej Siewior]

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/arch/arm/mach-orion5x/common.c
index eafcc49..745af50 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -700,6 +700,7 @@ void __init orion5x_init(void)
 * Register watchdog driver
 */
orion5x_wdt_init();
+   orion5x_crypto_init();
 }
 
 /*
-- 
1.6.0.6

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

Re: [PATCH] arm/orion5x: add sram support for crypto

[Sebastian Andrzej Siewior]

* 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 mapping instead, just like 
Kirkwood does.
Oh now I remember: I've been counting the number possible window
mappings and they exceeded the number of availble slots. That's why I've
made it dynamic and board specific. However if this is not an issue than
static is probaly the better way.

 Since the driver got renamed, I'm going to send a delta if nothing else
 comes up.

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.
If you thing it is too early I can keep hacking in my own git tree until
I get the dmac_flush_range() hack out or so.

Nicolas

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  http://vger.kernel.org/majordomo-info.html

Re: [patch 0/3] crypto: padlock-aes: enable on VIA Nano

[Sebastian Andrzej Siewior]

* 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 to rebase it against Herbert's cryptodev tree [0].

I guess the bug can trigger on 32bit if you boot the affected 64bit CPU
in 32bit mode? I'm not sure if it is better to send this patches via
stable tree _or_ deactivate the padlock on affected CPUs.

[0]
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git

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  http://vger.kernel.org/majordomo-info.html

[WIP] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

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 +
 drivers/crypto/mv_crypto.c |  725 +++
 3 files changed, 735 insertions(+), 0 deletions(-)
 create mode 100644 drivers/crypto/mv_crypto.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e522144..fa564b5 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -157,6 +157,15 @@ config S390_PRNG
  ANSI X9.17 standard. The PRNG is usable via the char device
  /dev/prandom.
 
+config CRYPTO_DEV_MARVELL_CRYPTO_ENGINE
+   tristate Marvell's Cryptographic Engine
+   depends on PLAT_ORION
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES
+   help
+ This driver allows you utilize the cryptographic engine which can be
+ found on certain SoC like QNAP's TS-209.
+
 config CRYPTO_DEV_HIFN_795X
tristate Driver HIFN 795x crypto accelerator chips
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 73557b2..6020a58 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CRYPTO_ENGINE) += mv_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
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
@@ -0,0 +1,725 @@
+/*
+ * Support for Marvell's crypto engine which can be found on some Orion5X
+ * boards.
+ *
+ * Author: Sebastian Andrzej Siewior  sebastian at breakpoint dot cc 
+ * License: GPL
+ *
+ */
+#include linux/io.h
+#include linux/crypto.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/scatterlist.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/kthread.h
+#include crypto/algapi.h
+#include crypto/aes.h
+
+enum engine_status {
+   engine_idle,
+   engine_busy,
+   engine_w_dequeue,
+};
+
+struct req_progress {
+   struct sg_mapping_iter src_sg_it;
+   struct sg_mapping_iter dst_sg_it;
+
+   /* src mostly */
+   int this_sg_b_left;
+   int src_start;
+   int crypt_len;
+   /* dst mostly */
+   int this_dst_sg_b_left;
+   int dst_start;
+   int total_req_bytes;
+};
+
+struct crypto_priv {
+   void __iomem *reg;
+   void __iomem *sram;
+   int irq;
+   struct task_struct *queue_th;
+
+   spinlock_t lock;
+   struct crypto_queue queue;
+   enum engine_status eng_st;
+   struct ablkcipher_request *cur_req;
+   struct req_progress p;
+};
+
+static struct crypto_priv *cpg;
+
+static void reg_write(void __iomem *mem, u32 val)
+{
+   __raw_writel(val, mem);
+}
+
+static u32 reg_read(void __iomem *mem)
+{
+   return __raw_readl(mem);
+}
+
+#define DIGEST_INITIAL_VAL_A   0xdd00
+#define DES_CMD_REG0xdd58
+
+#define SEC_ACCEL_CMD  0xde00
+#define SEC_CMD_EN_SEC_ACCL0   (1  0)
+#define SEC_CMD_EN_SEC_ACCL1   (1  1)
+#define SEC_CMD_DISABLE_SEC(1  2)
+
+#define SEC_ACCEL_DESC_P0  0xde04
+#define SEC_DESC_P0_PTR(x) (x)
+
+#define SEC_ACCEL_DESC_P1  0xde14
+#define SEC_DESC_P1_PTR(x) (x)
+
+#define SEC_ACCEL_CFG  0xde08
+#define SEC_CFG_STOP_DIG_ERR   (1  0)
+#define SEC_CFG_CH0_W_IDMA (1  7)
+#define SEC_CFG_CH1_W_IDMA (1  8)
+#define SEC_CFG_ACT_CH0_IDMA   (1  9)
+#define SEC_CFG_ACT_CH1_IDMA   (1  10)
+
+#define SEC_ACCEL_STATUS   0xde0c
+#define SEC_ST_ACT_0   (1  0)
+#define SEC_ST_ACT_1   (1  1)
+
+
+/*
+ * FPGA_INT_STATUS looks like a FPGA leftover and is undocumented. I asumme
+ * that it was part of an IRQ-controller in FPGA and someone forgot to remove
+ * it while switching to the core and moving to SEC_ACCEL_INT_STATUS.
+ */
+#define FPGA_INT_STATUS0xdd68
+#define SEC_ACCEL_INT_STATUS   0xde20
+#define SEC_INT_AUTH_DONE  (1  0)
+#define SEC_INT_DES_E_DONE (1  1)
+#define SEC_INT_AES_E_DONE (1  2)
+#define SEC_INT_AES_D_DONE (1  3)
+#define SEC_INT_ENC_DONE   (1  4)
+#define SEC_INT_ACCEL0_DONE(1  5)
+#define SEC_INT_ACCEL1_DONE(1  6)
+#define SEC_INT_ACC0_IDMA_DONE (1  7)
+#define SEC_INT_ACC1_IDMA_DONE (1  8)
+
+#define SEC_ACCEL_INT_MASK 0xde24
+
+#define AES_KEY_LEN(8 * 4)
+
+struct sec_accel_config {
+
+   u32 config;
+#define CFG_OP_MAC_ONLY0
+#define CFG_OP_CRYPT_ONLY  1
+#define CFG_OP_MAC_CRYPT   2
+#define CFG_OP_CRYPT_MAC   3
+#define

Re: VIA Padlock driver no longer loads automatically

[Sebastian Andrzej Siewior]

* 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 which need fallback to *-all to get them
probed/loaded after the generic algorithm. The same load/fallback/test
pattern exist for the s390 aes for instance. Should it be renamed as
well?

commit acd246b7494c629aa617da49716409566cf52149
Author: Herbert Xu herb...@gondor.apana.org.au
Date:   Tue Apr 21 13:55:20 2009 +0800

crypto: padlock - Revert aes-all alias to aes

Since the padlock-aes driver doesn't require a fallback (it's
only padlock-sha that does), it should use the aes alias rather
than aes-all so that ones that do need a fallback can use it.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au

diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 3f0fdd1..856b3cc 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -489,4 +489,4 @@ MODULE_DESCRIPTION(VIA PadLock AES algorithm support);
 MODULE_LICENSE(GPL);
 MODULE_AUTHOR(Michal Ludvig);
 
-MODULE_ALIAS(aes-all);
+MODULE_ALIAS(aes);

Thanks,
-- 

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  http://vger.kernel.org/majordomo-info.html

Re: VIA Padlock driver no longer loads automatically

[Sebastian Andrzej Siewior]

* 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 from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [WIP/RFC] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

* 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 *sram;
 +int irq;
 +struct task_struct *queue_th;
 +
 +spinlock_t lock;
 +struct crypto_queue queue;
 +enum engine_status eng_st;
 +struct ablkcipher_request *cur_req;
 +struct req_progress p;
 +};
 +
 +static struct crypto_priv *cpg;
 +

This rises several questions: why some of its fields are accessed under
the lock and others are modified without. Some of them are only used in
the kernel thread, while others are used in request context.
Please document locking bits in the code.
Will do. Right now, I could switch to the _bh spinlock since it is only
required to access the queue. Earlier I planned to enqueue the first
request directly on the hw but then I got into the scatter walk.


 +static void reg_write(void __iomem *mem, u32 val)
 +{
 +__raw_writel(val, mem);
 +}
 +
 +static u32 reg_read(void __iomem *mem)
 +{
 +return __raw_readl(mem);
 +}
 +

Seems like you do not like underscores otherwise you would use those
functions directly.
Yes, I could do so. I wasn't sure whether those are the correct
functions to access the memory. If there were for some reason I could
replace them in one place. I switch to __.

 +
 +#define MAX_REQ_SIZE(8000)
 +

Parentheses are not needed.
yup.

 +irqreturn_t crypto_int(int irq, void *priv)
 +{
 +//  struct crypto_priv *cp = priv;
 +u32 val;
 +
 +val = reg_read(cpg-reg + SEC_ACCEL_INT_STATUS);
 +reg_write(cpg-reg + SEC_ACCEL_INT_MASK, 0);

Why do you ack interrupt before checking if interrupt belongs to
this driver?
I don't know. I better fix this.

 +if (!(val  SEC_INT_ACCEL0_DONE))
 +return IRQ_NONE;
 +
 +BUG_ON(cpg-eng_st != engine_busy);
 +cpg-eng_st = engine_w_dequeue;
 +wake_up_process(cpg-queue_th);
 +return IRQ_HANDLED;
 +}

-- 
   Evgeniy Polyakov

Thanks for looking over.

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  http://vger.kernel.org/majordomo-info.html

[WIP/RFC] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

This is version two of the the driver. New things:
- aes-ecb passes selftests
- aes-cbc passes selftests

The driver still does memcpy() from/to sram. To solve this, a dma driver
would be required but first I wanted to compare the performance between
now and nothing/generic aes. However I managed 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, 734 insertions(+), 0 deletions(-)
 create mode 100644 drivers/crypto/mav_crypto.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 01afd75..514fe78 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -157,6 +157,15 @@ config S390_PRNG
  ANSI X9.17 standard. The PRNG is usable via the char device
  /dev/prandom.
 
+config CRYPTO_DEV_MARVELL_CRYPTO_ENGINE
+   tristate Marvell's Cryptographic Engine
+   depends on PLAT_ORION
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES
+   help
+ This driver allows you utilize the cryptographic engine which can be
+ found on certain SoC like QNAP's TS-209.
+
 config CRYPTO_DEV_HIFN_795X
tristate Driver HIFN 795x crypto accelerator chips
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 9bf4a2b..9c7053c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
 obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CRYPTO_ENGINE) += mav_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
diff --git a/drivers/crypto/mav_crypto.c b/drivers/crypto/mav_crypto.c
new file mode 100644
index 000..07152e7
--- /dev/null
+++ b/drivers/crypto/mav_crypto.c
@@ -0,0 +1,724 @@
+/*
+ * Support for Marvell's crypto engine which can be found on some Orion5X
+ * boards.
+ *
+ * Author: Sebastian Andrzej Siewior  sebastian at breakpoint dot cc 
+ * License: GPL
+ *
+ */
+#include linux/io.h
+#include linux/crypto.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/scatterlist.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/kthread.h
+#include crypto/algapi.h
+#include crypto/aes.h
+
+enum engine_status {
+   engine_idle,
+   engine_busy,
+   engine_w_dequeue,
+};
+
+struct req_progress {
+   struct sg_mapping_iter src_sg_it;
+   struct sg_mapping_iter dst_sg_it;
+
+   /* src mostly */
+   int this_sg_b_left;
+   int src_start;
+   int crypt_len;
+   /* dst mostly */
+   int this_dst_sg_b_left;
+   int dst_start;
+   int total_req_bytes;
+};
+
+struct crypto_priv {
+   void __iomem *reg;
+   void __iomem *sram;
+   int irq;
+   struct task_struct *queue_th;
+
+   spinlock_t lock;
+   struct crypto_queue queue;
+   enum engine_status eng_st;
+   struct ablkcipher_request *cur_req;
+   struct req_progress p;
+};
+
+static struct crypto_priv *cpg;
+
+static void reg_write(void __iomem *mem, u32 val)
+{
+   __raw_writel(val, mem);
+}
+
+static u32 reg_read(void __iomem *mem)
+{
+   return __raw_readl(mem);
+}
+
+#define DIGEST_INITIAL_VAL_A   0xdd00
+#define DES_CMD_REG0xdd58
+
+#define SEC_ACCEL_CMD  0xde00
+#define SEC_CMD_EN_SEC_ACCL0   (1  0)
+#define SEC_CMD_EN_SEC_ACCL1   (1  1)
+#define SEC_CMD_DISABLE_SEC(1  2)
+
+#define SEC_ACCEL_DESC_P0  0xde04
+#define SEC_DESC_P0_PTR(x) (x)
+
+#define SEC_ACCEL_DESC_P1  0xde14
+#define SEC_DESC_P1_PTR(x) (x)
+
+#define SEC_ACCEL_CFG  0xde08
+#define SEC_CFG_STOP_DIG_ERR   (1  0)
+#define SEC_CFG_CH0_W_IDMA (1  7)
+#define SEC_CFG_CH1_W_IDMA (1  8)
+#define SEC_CFG_ACT_CH0_IDMA   (1  9)
+#define SEC_CFG_ACT_CH1_IDMA   (1  10)
+
+#define SEC_ACCEL_STATUS   0xde0c
+#define SEC_ST_ACT_0   (1  0)
+#define SEC_ST_ACT_1   (1  1)
+
+
+#define SEC_ACCEL_INT_STATUS   0xde20
+#define SEC_INT_AUTH_DONE  (1  0)
+#define SEC_INT_DES_E_DONE (1  1)
+#define SEC_INT_AES_E_DONE (1  2)
+#define SEC_INT_AES_D_DONE (1  3)
+#define SEC_INT_ENC_DONE   (1  4)
+#define SEC_INT_ACCEL0_DONE(1  5)
+#define SEC_INT_ACCEL1_DONE(1  6)
+#define SEC_INT_ACC0_IDMA_DONE (1  7)
+#define SEC_INT_ACC1_IDMA_DONE (1  8)
+
+#define SEC_ACCEL_INT_MASK 0xde24
+
+#define AES_KEY_LEN(8 * 4)
+
+struct sec_accel_config {
+
+   u32 config;
+#define CFG_OP_MAC_ONLY(0)
+#define CFG_OP_CRYPT_ONLY  (1)
+#define CFG_OP_MAC_CRYPT   (2)
+#define CFG_OP_CRYPT_MAC   (3)
+#define CFG_MACM_MD5

[PATCH 2/2] crypto/padlock: enable on x86_64

[Sebastian Andrzej Siewior]

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 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e522144..62ed61b 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -12,7 +12,7 @@ if CRYPTO_HW
 
 config CRYPTO_DEV_PADLOCK
tristate Support for VIA PadLock ACE
-   depends on X86_32  !UML
+   depends on !UML
select CRYPTO_ALGAPI
help
  Some VIA processors come with an integrated crypto engine
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 3f0fdd1..ddd27c7 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -154,7 +154,11 @@ static inline void padlock_reset_key(struct cword *cword)
int cpu = raw_smp_processor_id();
 
if (cword != per_cpu(last_cword, cpu))
+#ifndef CONFIG_X86_64
asm volatile (pushfl; popfl);
+#else
+   asm volatile (pushfq; popfq);
+#endif
 }
 
 static inline void padlock_store_cword(struct cword *cword)
@@ -208,10 +212,19 @@ static inline void padlock_xcrypt_ecb(const u8 *input, u8 
*output, void *key,
 
asm volatile (test $1, %%cl;
  je 1f;
+#ifndef CONFIG_X86_64
  lea -1(%%ecx), %%eax;
  mov $1, %%ecx;
+#else
+ lea -1(%%rcx), %%rax;
+ mov $1, %%rcx;
+#endif
  .byte 0xf3,0x0f,0xa7,0xc8;  /* rep xcryptecb */
+#ifndef CONFIG_X86_64
  mov %%eax, %%ecx;
+#else
+ mov %%rax, %%rcx;
+#endif
  1:
  .byte 0xf3,0x0f,0xa7,0xc8   /* rep xcryptecb */
  : +S(input), +D(output)
-- 
1.6.2

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

enable padlock on x86_64

[Sebastian Andrzej Siewior]

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 not present in 32bit
  path but are now. They might be usefull if this CPU is booted in 32bit
  mode.
- the fixups which are executed via -c_early_init() are now executed
  again via -c_init(). This was done in the 64bit path and without this I
  lost the constant_tsc flag. However, tsc is not useable due to
| [2.023006] Marking TSC unstable due to TSC halts in idle
| [2.500082] Clocksource tsc unstable (delta = -326436711 ns)

The two patches are against the current tip tree. A version of patch 1
against current -rc8 is available at [0].

[0] http://download.breakpoint.cc/0001-x86-centaur-merge-32-64-bit-version.patch

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  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] x86/centaur: merge 32 64 bit version

[Sebastian Andrzej Siewior]

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 |   17 +
 arch/x86/kernel/cpu/Makefile |3 +--
 arch/x86/kernel/cpu/centaur.c|   30 +-
 arch/x86/kernel/cpu/centaur_64.c |   37 -
 4 files changed, 27 insertions(+), 60 deletions(-)
 delete mode 100644 arch/x86/kernel/cpu/centaur_64.c

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index a95eaf0..924e156 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -456,24 +456,9 @@ config CPU_SUP_AMD
 
  If unsure, say N.
 
-config CPU_SUP_CENTAUR_32
+config CPU_SUP_CENTAUR
default y
bool Support Centaur processors if PROCESSOR_SELECT
-   depends on !64BIT
-   ---help---
- This enables detection, tunings and quirks for Centaur processors
-
- You need this enabled if you want your kernel to run on a
- Centaur CPU. Disabling this option on other types of CPUs
- makes the kernel a tiny bit smaller. Disabling it on a Centaur
- CPU might render the kernel unbootable.
-
- If unsure, say N.
-
-config CPU_SUP_CENTAUR_64
-   default y
-   bool Support Centaur processors if PROCESSOR_SELECT
-   depends on 64BIT
---help---
  This enables detection, tunings and quirks for Centaur processors
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 24733b4..3efcb2b 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -19,8 +19,7 @@ obj-$(CONFIG_X86_CPU_DEBUG)   += cpu_debug.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= intel.o
 obj-$(CONFIG_CPU_SUP_AMD)  += amd.o
 obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
-obj-$(CONFIG_CPU_SUP_CENTAUR_32)   += centaur.o
-obj-$(CONFIG_CPU_SUP_CENTAUR_64)   += centaur_64.o
+obj-$(CONFIG_CPU_SUP_CENTAUR)  += centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)   += umc.o
 
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 983e083..946814a 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -276,7 +276,7 @@ static void __cpuinit init_c3(struct cpuinfo_x86 *c)
 */
c-x86_capability[5] = cpuid_edx(0xC001);
}
-
+#ifdef CONFIG_X86_32
/* Cyrix III family needs CX8  PGE explicitly enabled. */
if (c-x86_model = 6  c-x86_model = 9) {
rdmsr(MSR_VIA_FCR, lo, hi);
@@ -288,6 +288,11 @@ static void __cpuinit init_c3(struct cpuinfo_x86 *c)
/* Before Nehemiah, the C3's had 3dNOW! */
if (c-x86_model = 6  c-x86_model  9)
set_cpu_cap(c, X86_FEATURE_3DNOW);
+#endif
+   if (c-x86 == 0x6  c-x86_model = 0xf) {
+   c-x86_cache_alignment = c-x86_clflush_size * 2;
+   set_cpu_cap(c, X86_FEATURE_REP_GOOD);
+   }
 
display_cacheinfo(c);
 }
@@ -316,16 +321,25 @@ enum {
 static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
 {
switch (c-x86) {
+#ifdef CONFIG_X86_32
case 5:
/* Emulate MTRRs using Centaur's MCR. */
set_cpu_cap(c, X86_FEATURE_CENTAUR_MCR);
break;
+#endif
+   case 6:
+   if (c-x86_model = 0xf)
+   set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
+   break;
}
+#ifdef CONFIG_X86_64
+   set_cpu_cap(c, X86_FEATURE_SYSENTER32);
+#endif
 }
 
 static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
 {
-
+#ifdef CONFIG_X86_32
char *name;
u32  fcr_set = 0;
u32  fcr_clr = 0;
@@ -337,8 +351,10 @@ static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
 * 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway
 */
clear_cpu_cap(c, 0*32+31);
-
+#endif
+   early_init_centaur(c);
switch (c-x86) {
+#ifdef CONFIG_X86_32
case 5:
switch (c-x86_model) {
case 4:
@@ -442,16 +458,20 @@ static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
}
sprintf(c-x86_model_id, WinChip %s, name);
break;
-
+#endif
case 6:
init_c3(c);
break;
}
+#ifdef CONFIG_X86_64
+   set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
+#endif
 }
 
 static unsigned int __cpuinit
 centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)
 {
+#ifdef CONFIG_X86_32
/* VIA C3 CPUs (670-68F) need further shifting. */
if ((c-x86 == 6)  ((c-x86_model == 7) || (c-x86_model == 8)))
size = 8;
@@ -464,7 +484,7 @@ centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size

Re: enable padlock on x86_64

[Sebastian Andrzej Siewior]

* 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 
functionality might not be fully present on 32-bit? ]

Yep, it is fine.
#1 in, #2 not will not result in any difference to what we have now.
#2 in, #1 not will result in padlock not detected while loading the
module and -ENODEV.

Then in 2.6.30 once both the x86 tree and the crypto tree are 
merged we'll have both changes combined.

Does that sound good?
I'm fine with this, but last word is Herbert's :)

   Ingo

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  http://vger.kernel.org/majordomo-info.html

Re: [WIP] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

* 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 decryption
with a 16 byte long key. The other two key sizes failed. Probably the
the key slots are different. Currently I have no idea what's wrong.

[Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not 
sure why your code fail, but I can refer you to our driver as a reference, 
maybe you can find it as a good reference also for other issues.

This is an old LSP for the 5182, but the crypto driver supposed to work on the 
5182 just fine:
http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz

Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/
Oh thanks a lot. I take a look on this.

I also wanted to point that the crypto engine on the 5182 passed 2 more 
evolutions after the 5182, which included:
- Add a dedicated DMA to the crypto unit.
Does this mean that the crypto unit itself is now able to copy data and
I don't have to use the idma for that? That sounds great.

- Support only one channel.
- Fix main erratas.
- Decrease SRAM size to 2K.
- Add support for chain mode.
I can understand that, since SRAM is not that cheap and with chaining
support it should not matter.

Maybe you should take those into account in your design to allow support for 
other crypto versions in the future.
If you need more details pls check the security chapter on:
http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf
I take a look on this as well.

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  http://vger.kernel.org/majordomo-info.html

Re: [WIP] crypto: add support for Orion5X crypto engine

[Sebastian Andrzej Siewior]

* 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 unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hanging modprobe aes_s390

[Sebastian Andrzej Siewior]

* 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 have a problem with the geode here. That one
is loaded via PCI id probing. I'm going to check on that once I figured
out where the devel board is.

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  http://vger.kernel.org/majordomo-info.html

Re: alg: cipher: Test 1 failed on encryption for aes-asm

[Sebastian Andrzej Siewior]

* 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 hazardous.
You don't have to trick with Makefiles. You could use subsys_initcall()
in cryptomgr  algapi and for instance rootfs_initcall() for the generic
aes to ensure that it comes before the asm version but after the
subsystem. _Or_ you could use late_initcall() in the asm version. After
a second look I thing the late initcall variant looks better.

However, since the table isn't that large we might as well compute
it once and for all, like this:

crypto: aes - Precompute tables
That patch is big but should not break anything. I still prefer to fix
it the other way via the init call order: it is smaller patch and would
be a nice example for further modules which might rely on each other
like aes does.

No matter what you pick as your final solution, should I send a
's/module_init/subsys_initcall/' patch for cryptomgr  algapi?

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  http://vger.kernel.org/majordomo-info.html

Re: alg: cipher: Test 1 failed on encryption for aes-asm

[Sebastian Andrzej Siewior]

* 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. aes_x86_64 can
not work before aes_generic is initialized, so that cause register
time testing failed with following error message:

Couldn't we link arch/x/crypto after crypto ?

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  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions

[Sebastian Andrzej Siewior]

* 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 sollution could be

The general x86 implementation is used as the fall back for new AES-NI
based implementation. Because AES-NI can not be used in kernel soft_irq
context. If crypto layer is used to access general x86 implementation,
we will have tfm_ctx alignment issue, because AES-NI need tfm_ctx to be
16 byte aligned.

 - unless I've read the code too fast, it does not work if someone sets the
   key in user context and starts an encryption in softirq context.

Oh, I should use struct crypto_aes_ctx instead of define struct aes_ctx.
The tfm_ctx definition is different. I will fix this. Except that, is
there any other issue?
Now I see what you have done. You are sharing the same tfm between your
aes version and the old asm version. Both assume different private
data (aes_ctx vs crypto_aes_ctx) so this should not work.

 - aes_ctx is somehow bad. You are using this for a function and a
   struct. An Intel prefix would be nice (in case of the struct). On a
   second thought, any reason why you can't use crypto_aes_ctx?

Yes. I will use that. The only issue is that AES-NI need scheduled key
to be 16 bytes aligned, so we need move key_length in struct
crypto_aes_ctx to the end of the struct.
You have to it if you want to bypass the crypto layer and call asm
functions directly and I'm not sure whether bypassing the crypto layer
is a good thing. Both asm routines (the 32bit and 64bit) assume that
keylen ist at +0 followed by enc key, dec key. Ach and they don't do the
ALIGN thing.

Herbert what do you thing?

 - Is this an Intel thing or is going to be part of X86 and also
   available to others (like mmx). In that case the Intel prefix may be
   wrong.

Now it is an Intel thing. But in the future it may become part of x86.
Intel named it as AES-NI (AES New Instructions), but name like
aes_ni_aes_set_key is not good too. Does aes_ni_set_key sound better?
The latter is fine. I just want to avoid having several and different
aes_set_key() around.

 - does the cpu support more than just pure aes e.g. block modes? In case
   it does not, does the perfomance improve if you implement lets say
   cbc(aes) and do the xor with sse in order to save a few
   kernel_fpu_begin() calls? I'm just asking because I saw a similar
   thing and PowerPC and the AltiVec unit. Maybe it is cheap on x86 :)

Yes. AES-NI can benefit not only block modes. And the pipeline
implementation of AES-NI can benefit cbc(aes) decryption and ctr(aes)
even more (described in detail in white paper). We will work on that.
Ah okay. So depending on how expensive kernel_fpu_begin() really is it
might be slower for just the cipher (i.e. in xts(aes) where xts calls
you for every 16bytes).


Best Regards,
Huang Ying


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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: add test vectors for skein256/512/1024

[Sebastian Andrzej Siewior]

* 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 the tables + vim
 magiced them. So maybe code may missbehave on requests lengths which are
 not a multiple of 4 or the vectors can not be used due to some other
 limitations that I've overseen.

Okay, that was a false positive :)
The untouched reference implementation outputs the same hash. The
additional information (tree, ...) is part of the third argument in
Skein_XXX_InitExt() which isn't used. So we can safely drop the third
test vector.


   Jeff

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: add test vectors for skein256/512/1024

[Sebastian Andrzej Siewior]

* 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 the tables + vim
 magiced them. So maybe code may missbehave on requests lengths which are
 not a multiple of 4 or the vectors can not be used due to some other
 limitations that I've overseen.

 Another thought:  did you verify that the test vectors' output sizes 
 matched the Linux kernel's?
It should. All have something like:
| :Skein-512:   512-bit hash, msgLen = 8 bits
512 algo, 512 output. 

The third one has:
| :Skein-512:   512-bit hash, msgLen =  2040 bits. Tree: leaf=02, node=02, 
maxLevels=02
So it looks like the same except that it has the Tree: leaf node
attribes as well. So maybe this is something special maybe not. As I
browsed the .txt files for other vectors I did not find any where msglen
wasn't a multiple of 4 bytes (except some odd ones where msgles was 7
bits). Maybe I did not look close enough.

   Jeff

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: add test vectors for skein256/512/1024

[Sebastian Andrzej Siewior]

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 the tables + vim
magiced them. So maybe code may missbehave on requests lengths which 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 +-
 3 files changed, 216 insertions(+), 1 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 28a45a1..c7717e8 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -661,6 +661,18 @@ static void do_test(int m)
tcrypt_test(ecb(seed));
break;
 
+   case 44:
+   tcrypt_test(skein256);
+   break;
+
+   case 45:
+   tcrypt_test(skein512);
+   break;
+
+   case 46:
+   tcrypt_test(skein1024);
+   break;
+
case 100:
tcrypt_test(hmac(md5));
break;
@@ -851,6 +863,18 @@ static void do_test(int m)
test_hash_speed(rmd320, sec, generic_hash_speed_template);
if (mode  300  mode  400) break;
 
+   case 318:
+   test_hash_speed(skein256, sec, generic_hash_speed_template);
+   if (mode  300  mode  400) break;
+
+   case 319:
+   test_hash_speed(skein512, sec, generic_hash_speed_template);
+   if (mode  300  mode  400) break;
+
+   case 320:
+   test_hash_speed(skein1024, sec, generic_hash_speed_template);
+   if (mode  300  mode  400) break;
+
case 399:
break;
 
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index b828c6c..bc6fc7f 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1693,6 +1693,33 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+   .alg = skein1024,
+   .test = alg_test_hash,
+   .suite = {
+   .hash = {
+   .vecs = skein1024_tv_template,
+   .count = SKEIN1024_TEST_VECTORS
+   }
+   }
+   }, {
+   .alg = skein256,
+   .test = alg_test_hash,
+   .suite = {
+   .hash = {
+   .vecs = skein256_tv_template,
+   .count = SKEIN256_TEST_VECTORS
+   }
+   }
+   }, {
+   .alg = skein512,
+   .test = alg_test_hash,
+   .suite = {
+   .hash = {
+   .vecs = skein512_tv_template,
+   .count = SKEIN512_TEST_VECTORS
+   }
+   }
+   }, {
.alg = tgr128,
.test = alg_test_hash,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index dee94d9..ebed56f 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -27,7 +27,7 @@ struct hash_testvec {
char *plaintext;
char *digest;
unsigned char tap[MAX_TAP];
-   unsigned char psize;
+   u16 psize;
unsigned char np;
unsigned char ksize;
 };
@@ -986,6 +986,170 @@ static struct hash_testvec tgr128_tv_template[] = {
 };
 
 /*
+ * SKEIN uses test vectors
+ *  from http://www.schneier.com/code/skein_NIST_CD_101308.zip
+ *  NIST/CD/KAT_MCT/skein_golden_kat_short.txt
+ */
+#define SKEIN256_TEST_VECTORS 2
+static struct hash_testvec skein256_tv_template[] = {
+   {
+   /* :Skein-256:   256-bit hash, msgLen = 8 bits */
+   .plaintext = \xff,
+   .psize  = 1,
+   .digest = 
\xa4\x7b\xe7\x1a\x18\x5b\xa0\xaf\x82\x0b\x3c\xe8\x45\xa3\xd3\x5a
+   
\x80\xec\x64\xf9\x6a\x0d\x6a\x36\xe3\xf5\x36\x36\x24\xd8\xa0\x91,
+   }, {
+   /* :Skein-256:   256-bit hash, msgLen =   512 bits */
+   .plaintext = 
\xff\xfe\xfd\xfc\xfb\xfa\xf9\xf8\xf7\xf6\xf5\xf4\xf3\xf2\xf1\xf0
+   
\xef\xee\xed\xec\xeb\xea\xe9\xe8\xe7\xe6\xe5\xe4\xe3\xe2\xe1\xe0
+   
\xdf\xde\xdd\xdc\xdb\xda\xd9\xd8\xd7\xd6\xd5\xd4\xd3\xd2\xd1\xd0
+   
\xcf\xce\xcd\xcc\xcb\xca\xc9\xc8\xc7\xc6\xc5\xc4\xc3\xc2\xc1\xc0,
+   .psize  = 64,
+   .digest = 
\xfa\x1a\x76\x2b\x6b\x1c\x72\xb7\x0d\x52\x92\x63\x53\xe1\x0e\xb8
+   
\xfb\x0e\xdd\x73\x13\xda\x20\xa2\x41\x31\x80\xb8\xe2\x89\xb8\x72,
+   }, {
+   /* :Skein-256:   256-bit hash, msgLen =  1016 bits. Tree: 
leaf=02, node=02, maxLevels=02 */
+   .plaintext

Re: [PATCH] AMCC Crypto4xx Device Driver v2

[Sebastian Andrzej Siewior]

* 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
 +++ b/arch/powerpc/boot/dts/kilauea.dts
 @@ -1,4 +1,4 @@
 -/*
 +/* 
   * Device Tree Source for AMCC Kilauea (405EX)
   *
Usually we are removing leading/trailing blanks. Not the other way
around. 
I haven't seen this change in the submit at Date: Fri, 19 Sep 2008
16:46:43 -0700. Is this an updated version or does my mailbox leak
emails?

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html