Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> >> 2. non slave channel requests, where only the functionality matters, like
> >> memcpy, interleaved, memset, etc.
> >> We could have a simple:
> >> dma_request_channel(mask);
> >>
> >> But looking at the drivers using dmaengine legacy dma_request_channel() 
> >> API:
> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> >> drivers/misc/carma/carma-fpga.c 
> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> >> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> >> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> >> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> >>
> >> as examples.
> >> Not sure how valid are these...

I just had a look myself. carma has been removed fortunately in linux-next,
so we don't have to worry about that any more.

I assume that the sst-firmware.c case is a mistake, it should just use a
plain DMA_SLAVE and not DMA_MEMCPY.

Aside from these, everyone else uses either DMA_CYCLIC in addition to
DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is
redundant in slave drivers and can be removed.

> > It's usually not much harder to separate out the legacy case from
> > the normal dma_request_slave_channel_reason(), so those drivers don't
> > really need to use the unified compat API.
> 
> The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
> Currently there is no way to get the reason why the dma channel request fails
> when using the _compat() version of the API, which is used by drivers which
> can be used in DT or in legacy mode as well. Sure, they all could have local
> if(){}else{} for handling this, but it is not a nice thing.
> 
> As it was discussed instead of adding the _reason() version for the _compat
> call, we should simplify the dmaengine API for getting the channel and at the
> same time we will have ERR_PTR returned instead of NULL.

What I meant was that we don't need to handle them with the unified
simple interface. The users of DMA_CYCLIC can just keep using
an internal helper that only deals with the legacy case, or use
dma_request_slave() or whatever is the new API for the DT case.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Wed, Nov 18, 2015 at 04:51:54PM +0100, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
> > >
> > > I assume that the sst-firmware.c case is a mistake, it should just use a
> > > plain DMA_SLAVE and not DMA_MEMCPY.
> > 
> > Other way around.
> > 
> 
> Ok, I see. In that case I guess it also shouldn't call
> dmaengine_slave_config(), right? I don't think that's valid
> on a MEMCPY channel.

Yes it is not valid. In this case the dma driver should invoke a generic memcpy
and not need slave parameters, knowing the hw and reason for this (firmware
download to DSP memory), this doesn't qualify for slave case.
In fact filter function doesn't need a channel, any channel in this
controller will be good

-- 
~Vinod
--
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 1/5] crypto: Multi-buffer encryptioin infrastructure support

[Tim Chen]

On Wed, 2015-11-18 at 13:06 +0800, Herbert Xu wrote:
> On Tue, Nov 17, 2015 at 04:30:14PM -0800, Tim Chen wrote:
> > On Wed, 2015-11-18 at 08:07 +0800, Herbert Xu wrote:
> > > On Tue, Nov 17, 2015 at 02:59:29PM -0800, Tim Chen wrote:
> > > >
> > > > Herbert, would you prefer me to use ablkcipher scatter walk instead,
> > > > assuming the overhead of both walk are about the same?
> > > 
> > > Well since you are going to potentially sleep in the middle of
> > > an operation I'd think ablkcipher is required, no?
> > 
> > We're using blkcipher walk in the implementation. 
> > As long as we use kmap and instead of kmap_atomic,
> > it allows us to sleep in the middle of the walk.
> 
> What if you were called from an atomic context, such as IPsec?
> 

IPSec will invoke this multi-buffer encrypt with async request.
The work is done in crypto daemon, so it wouldn't be in atomic
context.  But anyway, I'm okay with switching to ablkcipher walk,
as long as it doesn't incur too much more overhead than blkcipher
walk.

Tim


--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi  wrote:
> Hi Vinod,
>
> bringing this old thread back to life as I just started to work on this.

What I remember we need to convert drivers to use new API meanwhile it
is good to keep old one to avoid patch storm which does nothing useful
(IIRC Russel's opinion).

On the other hand there are a lot of drivers that are used on the set
of platforms starting from legacy and abandoned ones (like AVR32) to
relatively new and newest.

And I'm not a fan of those thousands of API calls either.

-- 
With Best Regards,
Andy Shevchenko
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann  wrote:
> On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
>> >
>> > I assume that the sst-firmware.c case is a mistake, it should just use a
>> > plain DMA_SLAVE and not DMA_MEMCPY.
>>
>> Other way around.
>>
>
> Ok, I see. In that case I guess it also shouldn't call
> dmaengine_slave_config(), right? I don't think that's valid
> on a MEMCPY channel.

Hmm… That's right, though I suspect still one thing why it's done this
way. Let's ask Vinod and Liam about that.

-- 
With Best Regards,
Andy Shevchenko
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann  wrote:
> On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
>> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
>> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> >> 2. non slave channel requests, where only the functionality matters, like
>> >> memcpy, interleaved, memset, etc.
>> >> We could have a simple:
>> >> dma_request_channel(mask);
>> >>
>> >> But looking at the drivers using dmaengine legacy dma_request_channel() 
>> >> API:
>> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> >> drivers/misc/carma/carma-fpga.c 
>> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> >> drivers/misc/carma/carma-fpga-program.c 
>> >> DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> >> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
>> >> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
>> >>
>> >> as examples.
>> >> Not sure how valid are these...
>
> I just had a look myself. carma has been removed fortunately in linux-next,
> so we don't have to worry about that any more.
>
> I assume that the sst-firmware.c case is a mistake, it should just use a
> plain DMA_SLAVE and not DMA_MEMCPY.

Other way around.

-- 
With Best Regards,
Andy Shevchenko
--
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 v3] crypto: atmel: fix bogus select

[Arnd Bergmann]

>From 0d53d42a56e9a3769847fd03c703876f2c063fb4 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Tue, 27 Jan 2015 22:34:04 +0100
Subject: [PATCH] [SUBMITTED] crypto: atmel: fix bogus select

The Atmel at91 crypto driver unconditionally selects AT_HDMAC,
which results in a Kconfig warning if that driver is not enabled:

warning: (CRYPTO_DEV_ATMEL_AES) selects AT_HDMAC which has unmet direct 
dependencies (DMADEVICES && ARCH_AT91)

The crypto driver itself does not actually have a dependency
on a particular dma engine, other than this being the one that
is used in at91.

Removing the 'select' gets rid of the warning, but can cause
the driver to be unusable if the HDMAC is not enabled at the
same time. To work around that, this patch clarifies the runtime
dependency to be 'AT_HDMAC || AT_XDMAC', but adds an alternative
for COMPILE_TEST, which lets the driver get build on all systems.

The ARCH_AT91 dependency is implied by AT_XDMAC || AT_HDMAC now
and no longer needs to be listed separately.

Signed-off-by: Arnd Bergmann 
---
I found this one in my backlog, it still seems relevant and I forgot
to send a new version after the last round of comments.

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e043317e..5357bc1f9e4b 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -378,10 +378,9 @@ config CRYPTO_DEV_BFIN_CRC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on ARCH_AT91
+   depends on AT_XDMAC || AT_HDMAC || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_BLKCIPHER
-   select AT_HDMAC
help
  Some Atmel processors have AES hw accelerator.
  Select this if you want to use the Atmel module for

--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
> >
> > I assume that the sst-firmware.c case is a mistake, it should just use a
> > plain DMA_SLAVE and not DMA_MEMCPY.
> 
> Other way around.
> 

Ok, I see. In that case I guess it also shouldn't call
dmaengine_slave_config(), right? I don't think that's valid
on a MEMCPY channel.

Arnd
--
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 v3] crypto: atmel: fix bogus select

[kbuild test robot]

Hi Arnd,

[auto build test WARNING on: cryptodev/master]
[also build test WARNING on: v4.4-rc1 next-20151118]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/20151118-233706
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/crypto/atmel-aes.c:191:25: sparse: incompatible types in comparison 
expression (different type sizes)
   drivers/crypto/atmel-aes.c:447:25: sparse: incompatible types in comparison 
expression (different type sizes)
   drivers/crypto/atmel-aes.c:448:25: sparse: incompatible types in comparison 
expression (different type sizes)
   In file included from drivers/crypto/atmel-aes.c:17:0:
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_sg_copy':
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
>> drivers/crypto/atmel-aes.c:191:11: note: in expansion of macro 'min'
  count = min(count, buflen);
  ^
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_start':
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/crypto/atmel-aes.c:447:11: note: in expansion of macro 'min'
  count = min(dd->total, sg_dma_len(dd->in_sg));
  ^
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/crypto/atmel-aes.c:448:11: note: in expansion of macro 'min'
  count = min(count, sg_dma_len(dd->out_sg));
  ^
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-aes.c:17:
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_stop':
>> include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of 
>> type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned 
>> int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^
   include/linux/printk.h:252:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/crypto/atmel-aes.c:642:5: note: in expansion of macro 'pr_err'
pr_err("not all data converted: %u\n", count);
^
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_buff_init':
>> drivers/crypto/atmel-aes.c:669:20: warning: format '%d' expects argument of 
>> type 'int', but argument 3 has type 'size_t {aka long unsigned int}' 
>> [-Wformat=]
  dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
   ^
   drivers/crypto/atmel-aes.c:677:20: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
   ^

sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/crypto/atmel-aes.c:191:25: sparse: incompatible types in comparison 
>> expression (different type sizes)
   drivers/crypto/atmel-aes.c:447:25: sparse: incompatible types in comparison 
expression (different type sizes)
   drivers/crypto/atmel-aes.c:448:25: sparse: incompatible types in comparison 
expression (different type sizes)
   In file included from drivers/crypto/atmel-aes.c:17:0:
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_sg_copy':
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/crypto/atmel-aes.c:191:11: note: in expansion of macro 'min'
  count = min(count, buflen);
  ^
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_start':
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
lacks a cast
 (void) (&_min1 == &_min2);  \
^
   drivers/crypto/atmel-aes.c:447:11: note: in expansion of macro 'min'
  count = min(dd->total, sg_dma_len(dd->in_sg));
  ^
   include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 

Re: [PATCH v3] crypto: atmel: fix bogus select

[kbuild test robot]

Hi Arnd,

[auto build test WARNING on: cryptodev/master]
[also build test WARNING on: v4.4-rc1 next-20151118]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/20151118-233706
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: tile-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All warnings (new ones prefixed by >>):

   drivers/crypto/atmel-aes.c: In function 'atmel_aes_sg_copy':
>> drivers/crypto/atmel-aes.c:191:11: warning: comparison of distinct pointer 
>> types lacks a cast [enabled by default]
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_start':
   drivers/crypto/atmel-aes.c:447:11: warning: comparison of distinct pointer 
types lacks a cast [enabled by default]
   drivers/crypto/atmel-aes.c:448:11: warning: comparison of distinct pointer 
types lacks a cast [enabled by default]
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_stop':
>> drivers/crypto/atmel-aes.c:642:5: warning: format '%u' expects argument of 
>> type 'unsigned int', but argument 2 has type 'size_t' [-Wformat]
   drivers/crypto/atmel-aes.c: In function 'atmel_aes_buff_init':
>> drivers/crypto/atmel-aes.c:669:3: warning: format '%d' expects argument of 
>> type 'int', but argument 3 has type 'size_t' [-Wformat]
   drivers/crypto/atmel-aes.c:677:3: warning: format '%d' expects argument of 
type 'int', but argument 3 has type 'size_t' [-Wformat]

vim +191 drivers/crypto/atmel-aes.c

bd3c7b5c Nicolas Royer 2012-07-01  175  
bd3c7b5c Nicolas Royer 2012-07-01  176  sg_list = 
sg_next(sg_list);
bd3c7b5c Nicolas Royer 2012-07-01  177  if (!sg_list)
bd3c7b5c Nicolas Royer 2012-07-01  178  total = 0;
bd3c7b5c Nicolas Royer 2012-07-01  179  }
bd3c7b5c Nicolas Royer 2012-07-01  180  
bd3c7b5c Nicolas Royer 2012-07-01  181  return sg_nb;
bd3c7b5c Nicolas Royer 2012-07-01  182  }
bd3c7b5c Nicolas Royer 2012-07-01  183  
cadc4ab8 Nicolas Royer 2013-02-20  184  static int atmel_aes_sg_copy(struct 
scatterlist **sg, size_t *offset,
cadc4ab8 Nicolas Royer 2013-02-20  185  void *buf, 
size_t buflen, size_t total, int out)
cadc4ab8 Nicolas Royer 2013-02-20  186  {
cadc4ab8 Nicolas Royer 2013-02-20  187  unsigned int count, off = 0;
cadc4ab8 Nicolas Royer 2013-02-20  188  
cadc4ab8 Nicolas Royer 2013-02-20  189  while (buflen && total) {
cadc4ab8 Nicolas Royer 2013-02-20  190  count = 
min((*sg)->length - *offset, total);
cadc4ab8 Nicolas Royer 2013-02-20 @191  count = min(count, 
buflen);
cadc4ab8 Nicolas Royer 2013-02-20  192  
cadc4ab8 Nicolas Royer 2013-02-20  193  if (!count)
cadc4ab8 Nicolas Royer 2013-02-20  194  return off;
cadc4ab8 Nicolas Royer 2013-02-20  195  
cadc4ab8 Nicolas Royer 2013-02-20  196  
scatterwalk_map_and_copy(buf + off, *sg, *offset, count, out);
cadc4ab8 Nicolas Royer 2013-02-20  197  
cadc4ab8 Nicolas Royer 2013-02-20  198  off += count;
cadc4ab8 Nicolas Royer 2013-02-20  199  buflen -= count;

:: The code at line 191 was first introduced by commit
:: cadc4ab8f6f73719ef0e124320cdd210d1c9ff3e crypto: atmel-aes - add support 
for latest release of the IP (0x130)

:: TO: Nicolas Royer <nico...@eukrea.com>
:: CC: Herbert Xu <herb...@gondor.apana.org.au>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: A new, fast and "unbreakable" encryption algorithm

[Sandy Harris]

On Wed, Nov 18, 2015 at 12:10 AM, Ismail Kizir  wrote:

> I've developed a new encryption algorithm, which dynamically changes
> the key according to plaintext and practically impossible to break.

There is a very long history of crypto whose author considers is
secure being quickly broken. This happens to nearly all methods
devised by amateurs and quite a few from professionals.

Despite that, amateurs like me & (I presume) you keep trying.
This is probably a good thing. Here's one of mine:
https://aezoo.compute.dtu.dk/doku.php?id=enchilada

> I also opened to public with MIT dual License.

This is excellent. Many people make claims for their
algorithm without publishing details, which is ludicrous
since no-one can analyze it without those details. You
have avoided that pitfall.

> I will present a paper on a Turkish National Inet-tr 2015 Symposium

A paper describing the design would make analysis
much easier than doing it from source code, and
like every other algorithm yours will need lots of
analysis before it might become sensible for
people to trust it.

I suggest you subscribe to the crypto list:
http://www.metzdowd.com/mailman/listinfo/cryptography

Once your paper is published, post a link there
to invite analysis.
--
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] hw_random: omap3-rom-rng: convert timer to delayed work

[Aaro Koskinen]

We cannot put the HW RNG to idle using a timer because we cannot disable
clocks from atomic context. Use a delayed work instead.

Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.

Reported-by: Sebastian Reichel 
Signed-off-by: Aaro Koskinen 
---

v2: Include workqueue.h instead of timer.h.

 drivers/char/hw_random/omap3-rom-rng.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
index a405cdc..8da14f1 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -29,11 +29,11 @@
 /* param1: ptr, param2: count, param3: flag */
 static u32 (*omap3_rom_rng_call)(u32, u32, u32);
 
-static struct timer_list idle_timer;
+static struct delayed_work idle_work;
 static int rng_idle;
 static struct clk *rng_clk;
 
-static void omap3_rom_rng_idle(unsigned long data)
+static void omap3_rom_rng_idle(struct work_struct *work)
 {
int r;
 
@@ -51,7 +51,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
u32 r;
u32 ptr;
 
-   del_timer_sync(_timer);
+   cancel_delayed_work_sync(_work);
if (rng_idle) {
clk_prepare_enable(rng_clk);
r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
@@ -65,7 +65,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
 
ptr = virt_to_phys(buf);
r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
-   mod_timer(_timer, jiffies + msecs_to_jiffies(500));
+   schedule_delayed_work(_work, msecs_to_jiffies(500));
if (r != 0)
return -EINVAL;
return 0;
@@ -102,7 +102,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   setup_timer(_timer, omap3_rom_rng_idle, 0);
+   INIT_DELAYED_WORK(_work, omap3_rom_rng_idle);
rng_clk = devm_clk_get(>dev, "ick");
if (IS_ERR(rng_clk)) {
pr_err("unable to get RNG clock\n");
@@ -118,6 +118,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
 
 static int omap3_rom_rng_remove(struct platform_device *pdev)
 {
+   cancel_delayed_work_sync(_work);
hwrng_unregister(_rom_rng_ops);
clk_disable_unprepare(rng_clk);
return 0;
-- 
2.4.0

--
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: A new, fast and "unbreakable" encryption algorithm

[Ismail Kizir]

Hello Sandy,

I agree every word you wrote.
That's why, I am trying to explain all my login publicly to
professionals. It's not rocket science. You will "just understand"
when you read:

Until today, we were looking from the "wrong side" I guess.

We were all thinking that we must have a "fixed" key which must never change!

Why?


I begun to ask that question: "Why the key must be fixed?" and changed
the paradigm.

And I decided to dynamically update the key in encyption and decryption process.


The essential logic of the algorithm is using the key as a "jump
table" which is dynamically updated with every "jump" we make.


To understand better how it functions, suppose that we don't have a
complex function.


Given the key body length(L) is a power of 2, and M is an integer to
tell us where we are in the "key body":


We just take the byte at position M of the key body, we XOR that byte
with the byte to be encrypted(X).

We increase the byte at position M and "jump to" (M+X)%L


So, every time we encrypt a byte, we also change the key. It's a bit
more complicated than this. But essentially this is the base logic. In
real function, we do more complex operations with more variables like
the salt(or nonce) value, the last byte we encrypted, the key
checksum(against related key attacks) etc.

Briefly, to decypher a ciphertext, a cracker needs to find out the
key, and, to find out the key, cracker needs to find out the
plaintext, because the key is dynamically updated according the
plaintext during encryption process: Impossible!


If you want to learn about the details, just take a look at the source
code I've published on this blog.


I believe this algorithm is the future of the encryption.


Use it! And please, let me know if you use: iki...@gmail.com

On Wed, Nov 18, 2015 at 9:31 PM, Sandy Harris  wrote:
> On Wed, Nov 18, 2015 at 12:10 AM, Ismail Kizir  wrote:
>
>> I've developed a new encryption algorithm, which dynamically changes
>> the key according to plaintext and practically impossible to break.
>
> There is a very long history of crypto whose author considers is
> secure being quickly broken. This happens to nearly all methods
> devised by amateurs and quite a few from professionals.
>
> Despite that, amateurs like me & (I presume) you keep trying.
> This is probably a good thing. Here's one of mine:
> https://aezoo.compute.dtu.dk/doku.php?id=enchilada
>
>> I also opened to public with MIT dual License.
>
> This is excellent. Many people make claims for their
> algorithm without publishing details, which is ludicrous
> since no-one can analyze it without those details. You
> have avoided that pitfall.
>
>> I will present a paper on a Turkish National Inet-tr 2015 Symposium
>
> A paper describing the design would make analysis
> much easier than doing it from source code, and
> like every other algorithm yours will need lots of
> analysis before it might become sensible for
> people to trust it.
>
> I suggest you subscribe to the crypto list:
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
> Once your paper is published, post a link there
> to invite analysis.
--
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 v3] crypto: atmel: fix bogus select

[Arnd Bergmann]

On Thursday 19 November 2015 02:17:21 kbuild test robot wrote:
> 
> [auto build test WARNING on: cryptodev/master]
> [also build test WARNING on: v4.4-rc1 next-20151118]
> 
> url:
> https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/20151118-233706
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git 
> master
> config: tile-allmodconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=tile 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/crypto/atmel-aes.c: In function 'atmel_aes_sg_copy':
> >> drivers/crypto/atmel-aes.c:191:11: warning: comparison of distinct pointer 
> >> types lacks a cast [enabled by default]
>drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_start':
>drivers/crypto/atmel-aes.c:447:11: warning: comparison of distinct pointer 
> types lacks a cast [enabled by default]
>drivers/crypto/atmel-aes.c:448:11: warning: comparison of distinct pointer 
> types lacks a cast [enabled by default]
>drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_stop':
> >> drivers/crypto/atmel-aes.c:642:5: warning: format '%u' expects argument of 
> >> type 'unsigned int', but argument 2 has type 'size_t' [-Wformat]
>drivers/crypto/atmel-aes.c: In function 'atmel_aes_buff_init':
> >> drivers/crypto/atmel-aes.c:669:3: warning: format '%d' expects argument of 
> >> type 'int', but argument 3 has type 'size_t' [-Wformat]
>drivers/crypto/atmel-aes.c:677:3: warning: format '%d' expects argument of 
> type 'int', but argument 3 has type 'size_t' [-Wformat]
> 
> 

Thanks for the report. I actually submitted a patch for these yesterday, but
I should have realized now that there is a dependency between the two patches,
and the other one needs to be applied first to avoid generating these
warnings in allmodconfig builds for all architectures.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> 2. non slave channel requests, where only the functionality matters, like
> memcpy, interleaved, memset, etc.
> We could have a simple:
> dma_request_channel(mask);
> 
> But looking at the drivers using dmaengine legacy dma_request_channel() API:
> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> 
> as examples.
> Not sure how valid are these...

It's usually not much harder to separate out the legacy case from
the normal dma_request_slave_channel_reason(), so those drivers don't
really need to use the unified compat API.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Peter Ujfalusi]

On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> 2. non slave channel requests, where only the functionality matters, like
>> memcpy, interleaved, memset, etc.
>> We could have a simple:
>> dma_request_channel(mask);
>>
>> But looking at the drivers using dmaengine legacy dma_request_channel() API:
>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> drivers/misc/carma/carma-fpga.c 
>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
>> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
>>
>> as examples.
>> Not sure how valid are these...
> 
> It's usually not much harder to separate out the legacy case from
> the normal dma_request_slave_channel_reason(), so those drivers don't
> really need to use the unified compat API.

The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
Currently there is no way to get the reason why the dma channel request fails
when using the _compat() version of the API, which is used by drivers which
can be used in DT or in legacy mode as well. Sure, they all could have local
if(){}else{} for handling this, but it is not a nice thing.

As it was discussed instead of adding the _reason() version for the _compat
call, we should simplify the dmaengine API for getting the channel and at the
same time we will have ERR_PTR returned instead of NULL.

-- 
Péter
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Peter Ujfalusi]

Hi Vinod,

bringing this old thread back to life as I just started to work on this.

On 06/24/2015 07:24 PM, Vinod Koul wrote:

>> We would end up with the following APIs, all returning with error code on 
>> failure:
>> dma_request_slave_channel(dev, name);
>> dma_request_channel_legacy(mask, fn, fn_param);
>> dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
>> dma_request_any_channel(mask);
> This is good idea but still we end up with 4 APIs. Why not just converge to
> two API, one legacy + memcpy + filer fn and one untimate API for slave?

Looked at the current API and it's use and, well, it is a bit confusing.

What I hoped that we can separate users to two category:
1. Slave channel requests, where we request a specific channel to handle HW
requests/triggers.
For this we could have:
dma_request_slave_channel(dev, name, fn, fn_param);

In DT/ACPI only drivers we can NULL out the fn and fn_param, in pure legacy
mode we null out the name, I would keep the dev so we could print dev specific
error in dmaengine core, but it could be optional, IN case of drivers used
both DT/ACPI and legacy mode all parameter can be filled and the core will
decide what to do.
For the legacy needs the dmaengine code would provide the mask dows with
DMA_SLAVE flag set.

2. non slave channel requests, where only the functionality matters, like
memcpy, interleaved, memset, etc.
We could have a simple:
dma_request_channel(mask);

But looking at the drivers using dmaengine legacy dma_request_channel() API:
Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG
drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY

as examples.
Not sure how valid are these...

Some drivers do pass fn and fn_param when requesting channel for DMA_MEMCPY
drivers/misc/mic/host/mic_device.h
drivers/mtd/nand/fsmc_nand.c
sound/soc/intel/common/sst-firmware.c (well, this request DMA_SLAVE capability
at the same time).

Some driver sets the fn_param w/o fn, which means fn_param is ignored.

So the
dma_request_slave_channel(dev, name, fn, fn_param);
dma_request_channel(mask);

almost covers the current users and would be pretty clean ;)

If we add the mask to the slave channel API - which will become universal,
drop in replacement for dma_request_channel, and we might have only one API:

dma_request_channel(dev, name, mask, fn, fn_param);

> 
> Internally we may have 4 APIs for cleaner handling...
> 
> Thoughts... ??

Yes, as we need to arrange the code internally to keep things neat.

-- 
Péter
--
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 1/5] crypto: Multi-buffer encryptioin infrastructure support

[Tim Chen]

On Thu, 2015-11-19 at 08:12 +0800, Herbert Xu wrote:
> On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote:
> >
> > IPSec will invoke this multi-buffer encrypt with async request.
> > The work is done in crypto daemon, so it wouldn't be in atomic
> > context.  But anyway, I'm okay with switching to ablkcipher walk,
> > as long as it doesn't incur too much more overhead than blkcipher
> > walk.
> 
> What if some other user called the blkcipher interface in an atomic
> context? You can't guarantee that your algorithm is only picked up
> through the ablkcipher interface, unless of course you do something
> like __driver-ctr-aes-aesni.

The __cbc-aes-aesni-mb algorithm is marked as internal algorithm 
with flag CRYPTO_ALG_INTERNAL, so it should not be picked up by other
algorithms and should only be invoked from mcryptd.

Anyway, I've udpated the aes_cbc_mb code with ablkcipher helper.
So I will be posting the new series with ablkcipher walk
after testing is done.

> 
> Hmm I was just looking at the sha_mb code and something doesn't
> look right.  For instance, can sha1_mb_update ever return
> -EINPROGRESS? This would be wrong as it's registered as an shash
> algorithm.

The __sha1-mb works in tandem with the outer layer of mcryptd 
aysnc algorithm. It does the completion for the outer 
async algorithm.  So as far as mcryptd is concerned, the
inner algorithm is synchronous in the sense that it is done
once it dispatch the job to __sha1-mb and don't have to worry about it.
I don't think mcryptd check for the return value from __sha1-mb
so it should be okay to return 0 instead of -EINPROGRESS.  
I'll double check that.

Tim

--
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: crypto: sahara - check return value of sg_nents_for_len

[Dan Carpenter]

Hello LABBE Corentin,

The patch 6c2b74d4774f: "crypto: sahara - check return value of
sg_nents_for_len" from Nov 4, 2015, leads to the following static
checker warning:

drivers/crypto/sahara.c:480 sahara_hw_descriptor_create()
warn: unsigned 'dev->nb_in_sg' is never less than zero.

drivers/crypto/sahara.c
   479  dev->nb_in_sg = sg_nents_for_len(dev->in_sg, dev->total);
   480  if (dev->nb_in_sg < 0) {
^
Unsigned is never less than zero.

   481  dev_err(dev->device, "Invalid numbers of src SG.\n");
   482  return dev->nb_in_sg;
   483  }

There are several other similar bugs as well:

drivers/crypto/sahara.c:485 sahara_hw_descriptor_create() warn: unsigned 
'dev->nb_out_sg' is never less than zero.
drivers/crypto/sahara.c:804 sahara_sha_hw_links_create() warn: unsigned 
'dev->nb_in_sg' is never less than zero.
drivers/crypto/picoxcell_crypto.c:298 spacc_sg_to_ddt() warn: unsigned 'nents' 
is never less than zero.
drivers/crypto/picoxcell_crypto.c:338 spacc_aead_make_ddts() warn: unsigned 
'src_nents' is never less than zero.
drivers/crypto/picoxcell_crypto.c:348 spacc_aead_make_ddts() warn: unsigned 
'dst_nents' is never less than zero.

regards,
dan carpenter
--
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 asynchronous compression support

[Li, Weigang]

On 10/16/2015 11:13 PM, Herbert Xu wrote:
> On Fri, Oct 16, 2015 at 11:11:00PM +0800, Weigang Li wrote:
>> This patch set introduces Asynchronous Compression API.
>> What is proposed is a new crypto type called crypto_acomp_type,
>> plus new struct acomp_alg and struct crypto_acomp, together with number
>> of helper functions to register acomp type algorithms and allocate tfm
>> instances. This is to make it similar to how the existing crypto API
>> works for the ablkcipher, and akcipher types.
>> The operations the new interface will provide are:
>>
>>  int (*compress)(struct acompress_request *req);
>>  int (*decompress)(struct acompress_request *req);
>>
>> The benefits it gives interface are:
>> - the new interface allows for asynchronous implementations and
>>scatterlist buffer that can use hardware to offload the compression
>>operations, the new asynchronous API can be called by the linux kernel
>>components (i.e., btrfs) who want to use hardware acceleration for data
>>compression.
>>
>> New helper functions have been added to allocate crypto_acomp instances
>> and invoke the operations to make it easier to use.
>>
>> Signed-off-by: Weigang Li 
> 
> Thanks for the patch! Joonsoo Kim is also working on the compression
> interface for zram.  Could you two collaborate and come up with one
> interface rather than two?
> 
> Cheers,
> 
Hello Herbert,

After sync-up with Joonsoo Kim, we think it may be not feasible for a s/w 
implementation of the sg-list based asynchronous interface, we propose separate 
interfaces (patches) for acomp & ccomp. The reasons are:
1. to support sg-list in the ccomp (like what shash/ahash did), the partial 
update is required, some algorithms do not support partial update (i.e., lzo), 
that means:
2. the format of output buffer (sg-list) will be different, e.g., the lzo need 
contain the "length" info for each block in the output sg-list in order to 
de-compression, while zlib doesn't need, then it is difficult to have a single 
async sg-list i/f.
3. to compress a sg-list buffer, the lzo also requires an intermediate buffer 
to save the output of a block, and copy it back to the sg-list output buffer, 
it will introduce the complexity and cost, we don't see value for sg-list 
support in a s/w compression.

Any suggestions?
--
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 1/5] crypto: Multi-buffer encryptioin infrastructure support

[Herbert Xu]

On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote:
>
> IPSec will invoke this multi-buffer encrypt with async request.
> The work is done in crypto daemon, so it wouldn't be in atomic
> context.  But anyway, I'm okay with switching to ablkcipher walk,
> as long as it doesn't incur too much more overhead than blkcipher
> walk.

What if some other user called the blkcipher interface in an atomic
context? You can't guarantee that your algorithm is only picked up
through the ablkcipher interface, unless of course you do something
like __driver-ctr-aes-aesni.

Hmm I was just looking at the sha_mb code and something doesn't
look right.  For instance, can sha1_mb_update ever return
-EINPROGRESS? This would be wrong as it's registered as an shash
algorithm.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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