[PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

[Sandy Harris]

Signed-off-by: Sandy Harris 
---
 drivers/char/random.c | 50 ++
 1 file changed, 46 insertions(+), 4 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index d0da5d8..e222e0f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -231,7 +231,7 @@
  * not be attributed to the Phil, Colin, or any of authors of PGP.
  *
  * Further background information on this topic may be obtained from
- * RFC 1750, "Randomness Recommendations for Security", by Donald
+ * RFC 4086, "Randomness Requirements for Security", by Donald
  * Eastlake, Steve Crocker, and Jeff Schiller.
  */
 
@@ -275,13 +275,19 @@
 /*
  * Configuration information
  */
+#ifdef CONFIG_RANDOM_INIT
+
+#include 
+
+#else
 #define INPUT_POOL_SHIFT   12
 #define INPUT_POOL_WORDS   (1 << (INPUT_POOL_SHIFT-5))
 #define OUTPUT_POOL_SHIFT  10
 #define OUTPUT_POOL_WORDS  (1 << (OUTPUT_POOL_SHIFT-5))
-#define SEC_XFER_SIZE  512
-#define EXTRACT_SIZE   10
+#endif
 
+#define EXTRACT_SIZE   10
+#define SEC_XFER_SIZE  512
 #define DEBUG_RANDOM_BOOT 0
 
 #define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
@@ -296,6 +302,27 @@
 #define ENTROPY_SHIFT 3
 #define ENTROPY_BITS(r) ((r)->entropy_count >> ENTROPY_SHIFT)
 
+/* sanity checks */
+
+#if ((ENTROPY_SHIFT+INPUT_POOL_SHIFT) >= 16)
+#ifndef CONFIG_64BIT
+#error *_SHIFT values problematic for credit_entropy_bits()
+#endif
+#endif
+
+#if ((INPUT_POOL_WORDS%16) || (OUTPUT_POOL_WORDS%16))
+#error Pool size not divisible by 16, which code assumes
+#endif
+
+#if (INPUT_POOL_WORDS < 32)
+#error Input pool less than a quarter of default size
+#endif
+
+#if (INPUT_POOL_WORDS < OUTPUT_POOL_WORDS)
+#error Strange configuration, input pool smalller than output
+#endif
+
+
 /*
  * The minimum number of bits of entropy before we wake up a read on
  * /dev/random.  Should be enough to do a significant reseed.
@@ -442,16 +469,23 @@ struct entropy_store {
 };
 
 static void push_to_pool(struct work_struct *work);
+
+#ifndef CONFIG_RANDOM_INIT
 static __u32 input_pool_data[INPUT_POOL_WORDS];
 static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
 static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS];
+#endif
 
 static struct entropy_store input_pool = {
.poolinfo = _table[0],
.name = "input",
.limit = 1,
.lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
-   .pool = input_pool_data
+#ifdef CONFIG_RANDOM_INIT
+   .pool = pools,
+#else
+   .pool = input_pool_data,
+#endif
 };
 
 static struct entropy_store blocking_pool = {
@@ -460,7 +494,11 @@ static struct entropy_store blocking_pool = {
.limit = 1,
.pull = _pool,
.lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock),
+#ifdef CONFIG_RANDOM_INIT
+   .pool = pools + INPUT_POOL_WORDS,
+#else
.pool = blocking_pool_data,
+#endif
.push_work = __WORK_INITIALIZER(blocking_pool.push_work,
push_to_pool),
 };
@@ -470,7 +508,11 @@ static struct entropy_store nonblocking_pool = {
.name = "nonblocking",
.pull = _pool,
.lock = __SPIN_LOCK_UNLOCKED(nonblocking_pool.lock),
+#ifdef CONFIG_RANDOM_INIT
+   .pool = pools + INPUT_POOL_WORDS + OUTPUT_POOL_WORDS,
+#else
.pool = nonblocking_pool_data,
+#endif
.push_work = __WORK_INITIALIZER(nonblocking_pool.push_work,
push_to_pool),
 };
-- 
2.5.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

[PATCH 6/7] Produces generated/random_init.h for random driver

[Sandy Harris]

Signed-off-by: Sandy Harris 
---
 scripts/gen_random.c | 260 +++
 1 file changed, 260 insertions(+)
 create mode 100644 scripts/gen_random.c

diff --git a/scripts/gen_random.c b/scripts/gen_random.c
new file mode 100644
index 000..07b447f
--- /dev/null
+++ b/scripts/gen_random.c
@@ -0,0 +1,260 @@
+/*
+ * Program to select random numbers for initialising things
+ * in the random(4) driver.
+ *
+ * A different implementation of basically the same idea is
+ * one of several kernel security enhancements at
+ * https://grsecurity.net/
+ *
+ * This program:
+ *
+ *limits the range of Hamming weights
+ *every byte has at least one bit 1, one 0
+ *different every time it runs
+ *
+ * data from /dev/urandom
+ * results suitable for inclusion by random.c
+ * writes to stdout, expecting makefile to redirect
+ *
+ * makefile should also delete the output file after it is
+ * used in compilation of random.c. This is more secure; it
+ * forces the file to be rebuilt and a new version used in
+ * every compile. It also prevents an enemy just reading an
+ * output file in the build directory and getting the data
+ * that is in use in the current kernel. This is not full
+ * protection since they might look in the kernel image,
+ * but it seems to be the best we can do.
+ *
+ * This falls well short of the ideal initialisation solution,
+ * which would give every installation (rather than every
+ * compiled kernel) a different seed. For that, see John
+ * Denker's suggestions at:
+ * http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
+ *
+ * On the other hand, neither sort of seed is necessary if
+ *either  you have a trustworthy hardware RNG
+ *or  you have secure stored data
+ * In those cases, the device can easily be initialised well; the
+ * only difficulty is to ensure this is done early enough.
+ *
+ * Inserting random data at compile time can do no harm and may
+ * sometimes make attacks harder. It is not an ideal solution, and
+ * not always necessary, but cheap and probably the best we can do
+ * during the build (rather than install) process.
+ *
+ * This is certainly done early enough and the data is random
+ * enough, but it is not necessarily secret enough.
+ *
+ * In some cases -- for example, a firewall machine that compiles
+ * its own kernel -- this alone might be enough to ensure secure
+ * initialisation, since only an enemy who already has root could
+ * discover this data. Of course even in those cases it should not
+ * be used alone, only as one layer of a defense in depth.
+ *
+ * In other cases -- a kernel that is compiled once then used in
+ * a Linux distro or installed on many devices -- this is likely
+ * of very little value. It complicates an attack somewhat, but
+ * it clearly will not stop a serious attacker and may not even
+ * slow them down much.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Configuration information
+ * moved from random.c
+ */
+#define INPUT_POOL_SHIFT   12
+#define INPUT_POOL_WORDS   (1 << (INPUT_POOL_SHIFT-5))
+#define OUTPUT_POOL_SHIFT  10
+#define OUTPUT_POOL_WORDS  (1 << (OUTPUT_POOL_SHIFT-5))
+
+#define TOTAL_POOL_WORDS  (INPUT_POOL_WORDS + 2*OUTPUT_POOL_WORDS)
+
+typedef uint32_t u32 ;
+
+int accept(u32) ;
+int hamming(u32);
+void do_block( int, char * ) ;
+void usage(void) ;
+
+int urandom ;
+
+int main(int argc, char **argv)
+{
+   if( (urandom = open("/dev/urandom", O_RDONLY)) == -1 )  {
+   fprintf(stderr, "gen_random_init: no /dev/urandom, cannot 
continue\n") ;
+   exit(1) ;
+   }
+   printf("/* File generated by gen_random_init.c */\n\n") ;
+   /*
+* print our constants into output file
+* ensuring random.c has the same values
+*/
+   printf("#define INPUT_POOL_WORDS %d\n", INPUT_POOL_WORDS) ; 
+   printf("#define OUTPUT_POOL_WORDS %d\n", OUTPUT_POOL_WORDS) ;
+   printf("#define INPUT_POOL_SHIFT %d\n\n", INPUT_POOL_SHIFT) ; 
+ 
+   /*
+* Initialise the pools with random data
+* This is done unconditionally
+*/
+   do_block( TOTAL_POOL_WORDS, "pools" ) ;
+
+#ifdef CONFIG_RANDOM_GCM
+
+#define ARRAY_ROWS  8  /* 4 pools get 2 constants each 
   */
+#define ARRAY_WORDS(4 * ARRAY_ROWS)/* 32-bit words, 128-bit 
constants */
+
+/*
+ * If we are using the GCM hash, set up an array of random
+ * constants for it.
+ *
+ * The choice of 32 words (eight 128-bit rows, 1024 bits) for
+ * this is partly arbitrary, partly reasoned. 256 bits would
+ * almost certainly be enough, but 1024 is convenient.
+ *
+ * The AES-GCM hash initialises its accumulator all-zero and uses
+ * a 128-bit multiplier, H. I chose instead to use two constants,
+ * one to initialise the accumulator and one in the role of H.
+ *
+ * This requires that a pair of 128-bit constants be used in 

[PATCH 5/7] Conditionals for CONFIG_RANDOM_INIT and CONFIG_RANDOM_GCM

[Sandy Harris]

Signed-off-by: Sandy Harris 
---
 drivers/char/Makefile | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index d8a7579..7d095e5 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -2,7 +2,30 @@
 # Makefile for the kernel character device drivers.
 #
 
-obj-y  += mem.o random.o
+obj-y  += mem.o
+
+ifeq ($(CONFIG_RANDOM_GCM),y)
+  random_c = random_gcm.c
+  random_o = random_gcm.o
+  random_no= random.o
+else
+  random_c = random.c
+  random_o = random.o
+  random_no= random_gcm.o
+endif
+obj-y  += $(random_o)
+
+# remove the generated file after use so that
+# a fresh one is built (by scripts/gen_random)
+# for every compile
+# remove random_no so it will not get linked
+ifeq ($(CONFIG_RANDOM_INIT),y)
+init-file = include/generated/random_init.h
+$(random_o): $(random_c) $(init-file)
+   $(CC) $< -o $@
+   $(Q) rm --force $(init-file) $(random_no)
+endif
+
 obj-$(CONFIG_TTY_PRINTK)   += ttyprintk.o
 obj-y  += misc.o
 obj-$(CONFIG_ATARI_DSP56K) += dsp56k.o
-- 
2.5.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

[PATCH 7/7] Create generated/random_init.h, used by random driver

[Sandy Harris]

Signed-off-by: Sandy Harris 
---
 Kbuild   | 21 +
 scripts/Makefile |  1 +
 2 files changed, 22 insertions(+)

diff --git a/Kbuild b/Kbuild
index f55cefd..494c665 100644
--- a/Kbuild
+++ b/Kbuild
@@ -5,6 +5,7 @@
 # 2) Generate timeconst.h
 # 3) Generate asm-offsets.h (may need bounds.h and timeconst.h)
 # 4) Check for missing system calls
+# 5) Generate random_init.h
 
 # Default sed regexp - multiline due to syntax constraints
 define sed-y
@@ -98,3 +99,23 @@ missing-syscalls: scripts/checksyscalls.sh $(offsets-file) 
FORCE
 
 # Keep these three files during make clean
 no-clean-files := $(bounds-file) $(offsets-file) $(timeconst-file)
+
+#
+# 5) Generate random_init.h
+
+ifdef CONFIG_RANDOM_INIT
+init-file := include/generated/random_init.h
+used-file := scripts/gen_random
+source-file := $(used-file).c
+always  += $(init-file)
+targets  += $(init-file)
+$(init-file) : $(used-file)
+   $(Q) $(used-file) > $(init-file)
+ifdef CONFIG_RANDOM_GCM
+$(used-file) : $(source-file)
+   $(CC) $< -DCONFIG_RANDOM_GCM -o $@
+else
+$(used-file) : $(source-file)
+   $(CC) $< -o $@
+endif
+endif
diff --git a/scripts/Makefile b/scripts/Makefile
index 1b26617..3cea546 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -18,6 +18,7 @@ hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
 hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
+hostprogs-$(CONFIG_RANDOM_INIT) += gen_random
 
 HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-- 
2.5.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

[PATCH 1/7] A couple of generated files

[Sandy Harris]

Signed-off-by: Sandy Harris 
---
 .gitignore | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.gitignore b/.gitignore
index fd3a355..dd80bfd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -112,3 +112,6 @@ all.config
 
 # Kdevelop4
 *.kdev4
+
+certs/x509_certificate_list
+scripts/gen_random
-- 
2.5.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: [PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

[kbuild test robot]

Hi Sandy,

[auto build test ERROR on: char-misc/char-misc-testing]
[also build test ERROR on: v4.3 next-20151106]

url:
https://github.com/0day-ci/linux/commits/Sandy-Harris/A-couple-of-generated-files/20151107-223540
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: the linux-review/Sandy-Harris/A-couple-of-generated-files/20151107-223540 
HEAD 4d000f20486e81f999bc1f5499f0cfb36b37db02 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/char/random.c:280:35: fatal error: generated/random_init.h: No such 
>> file or directory
   compilation terminated.

vim +280 drivers/char/random.c

   274  
   275  /*
   276   * Configuration information
   277   */
   278  #ifdef CONFIG_RANDOM_INIT
   279  
 > 280  #include 
   281  
   282  #else
   283  #define INPUT_POOL_SHIFT12

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


.config.gz
Description: Binary data

Re: [PATCH 5/7] Conditionals for CONFIG_RANDOM_INIT and CONFIG_RANDOM_GCM

[kbuild test robot]

Hi Sandy,

[auto build test ERROR on: char-misc/char-misc-testing]
[also build test ERROR on: v4.3 next-20151106]

url:
https://github.com/0day-ci/linux/commits/Sandy-Harris/A-couple-of-generated-files/20151107-223540
config: arm64-allyesconfig (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=arm64 

Note: the linux-review/Sandy-Harris/A-couple-of-generated-files/20151107-223540 
HEAD 4d000f20486e81f999bc1f5499f0cfb36b37db02 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/char/random_gcm.c:286:35: fatal error: generated/random_init.h: No 
>> such file or directory
#include 
  ^
   compilation terminated.

vim +286 drivers/char/random_gcm.c

da17cbfa Sandy Harris 2015-11-07  270  #define CREATE_TRACE_POINTS
da17cbfa Sandy Harris 2015-11-07  271  #include 
da17cbfa Sandy Harris 2015-11-07  272  
da17cbfa Sandy Harris 2015-11-07  273  /* #define ADD_INTERRUPT_BENCH */
da17cbfa Sandy Harris 2015-11-07  274  
da17cbfa Sandy Harris 2015-11-07  275  #ifndef CONFIG_RANDOM_INIT
da17cbfa Sandy Harris 2015-11-07  276  #error This version needs 
CONFIG_RANDOM_INIT
da17cbfa Sandy Harris 2015-11-07  277  #endif
da17cbfa Sandy Harris 2015-11-07  278  #ifndef CONFIG_RANDOM_GCM
da17cbfa Sandy Harris 2015-11-07  279  #error This version should not be 
compiled if CONFIG_RANDOM_GCM is not set
da17cbfa Sandy Harris 2015-11-07  280  #endif
da17cbfa Sandy Harris 2015-11-07  281  
da17cbfa Sandy Harris 2015-11-07  282  /*
da17cbfa Sandy Harris 2015-11-07  283   * Configuration information
da17cbfa Sandy Harris 2015-11-07  284   */
da17cbfa Sandy Harris 2015-11-07  285  
da17cbfa Sandy Harris 2015-11-07 @286  #include 
da17cbfa Sandy Harris 2015-11-07  287  
da17cbfa Sandy Harris 2015-11-07  288  #define EXTRACT_SIZE 16  
/* 128-bit GCM hash */
da17cbfa Sandy Harris 2015-11-07  289  #define SEC_XFER_SIZE512
da17cbfa Sandy Harris 2015-11-07  290  #define DEBUG_RANDOM_BOOT 0
da17cbfa Sandy Harris 2015-11-07  291  
da17cbfa Sandy Harris 2015-11-07  292  #define LONGS(x) (((x) + sizeof(unsigned 
long) - 1)/sizeof(unsigned long))
da17cbfa Sandy Harris 2015-11-07  293  
da17cbfa Sandy Harris 2015-11-07  294  /*

:: The code at line 286 was first introduced by commit
:: da17cbfaa5c53120c6c5797cf2dc6bd4123b6869 Different version of driver 
using hash from AES-GCM Compiled if CONFIG_RANDOM_GCM=y

:: TO: Sandy Harris <sandyinch...@gmail.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: Binary data

Re: [PATCH 1/7] A couple of generated files

[Jason Cooper]

Hey Sandy,

I know we talked  about this series offlist, but we need to fill in
folks who are seeing it for the first time.  Usually, this is done with
a coverletter (--coverletter for git format-patch).  No need to resend
before receiving feedback, but would you mind replying with a
description of the problem you're attempting to solve and how the series
solves it?

thx,

Jason.

On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  .gitignore | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index fd3a355..dd80bfd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -112,3 +112,6 @@ all.config
>  
>  # Kdevelop4
>  *.kdev4
> +
> +certs/x509_certificate_list
> +scripts/gen_random
> -- 
> 2.5.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: [PATCH 7/7] Create generated/random_init.h, used by random driver

[kbuild test robot]

Hi Sandy,

[auto build test ERROR on: char-misc/char-misc-testing]
[also build test ERROR on: v4.3 next-20151106]

url:
https://github.com/0day-ci/linux/commits/Sandy-Harris/A-couple-of-generated-files/20151107-223540
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/char/random_gcm.c:2366:28: sparse: non-ANSI function declaration of 
function 'mix_const_all'
   drivers/char/random_gcm.c:2379:21: sparse: non-ANSI function declaration of 
function 'big_mix'
   drivers/char/random_gcm.c:2443:21: sparse: non-ANSI function declaration of 
function 'top_mix'
   drivers/char/random_gcm.c:2518:26: sparse: non-ANSI function declaration of 
function 'clear_addmul'
   drivers/char/random_gcm.c:3208:25: sparse: non-ANSI function declaration of 
function 'init_random'
   drivers/char/random_gcm.c:3571:26: sparse: non-ANSI function declaration of 
function 'counter_any'
   drivers/char/random_gcm.c:3652:23: sparse: non-ANSI function declaration of 
function 'load_input'
   drivers/char/random_gcm.c:3702:27: sparse: non-ANSI function declaration of 
function 'load_constants'
   drivers/char/random_gcm.c:477:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:478:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:496:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:497:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:514:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:515:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:530:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:531:14: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:3471:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3474:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3477:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3488:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3495:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3496:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3497:25: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3517:9: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3541:9: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3547:17: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3555:24: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3555:58: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3555:51: sparse: cast from unknown type
   drivers/char/random_gcm.c:3560:17: sparse: undefined identifier 'counter'
   drivers/char/random_gcm.c:3709:58: sparse: undefined identifier 'ARRAY_WORDS'
   drivers/char/random_gcm.c:3709:25: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:2371:19: sparse: undefined identifier 'constants'
   drivers/char/random_gcm.c:2652:38: sparse: undefined identifier 'counter'
>> drivers/char/random_gcm.c:477:7: error: 'constants' undeclared here (not in 
>> a function)
 .A = constants,
  ^
   drivers/char/random_gcm.c: In function 'mix_first':
>> drivers/char/random_gcm.c:2652:31: error: 'counter' undeclared (first use in 
>> this function)
 addmul( (u8 *) accum, (u8 *) counter, 16, (u8 *) r->B) ;
  ^
   drivers/char/random_gcm.c:2652:31: note: each undeclared identifier is 
reported only once for each function it appears in
   drivers/char/random_gcm.c: In function 'count':
   drivers/char/random_gcm.c:3471:4: error: 'counter' undeclared (first use in 
this function)
   counter[1] += counter[3] ;
   ^
   drivers/char/random_gcm.c: In function 'buffer2counter':
   drivers/char/random_gcm.c:3541:2: error: 'counter' undeclared (first use in 
this function)
 counter[0] ^= jiffies ;
 ^
   drivers/char/random_gcm.c: In function 'load_constants':
>> drivers/char/random_gcm.c:3709:27: warning: left-hand operand of comma 
>> expression has no effect [-Wunused-value]
 for( i = 0, p = constants, ret = 1 ; ret && (i < ARRAY_WORDS) ; i++, p++ ) 
{
  ^
>> drivers/char/random_gcm.c:3709:51: error: 'ARRAY_WORDS' undeclared (first 
>> use in this function)
 for( i = 0, p = constants, ret = 1 ; ret && (i < ARRAY_WORDS) ; i++, p++ ) 
{
  ^

sparse warnings: (new ones prefixed by >>)

   drivers/char/random_gcm.c:2366:28: sparse: non-ANSI function declaration of 
function 'mix_const_all'
   drivers/char/random_gcm.c:2379:21: sparse: non-ANSI function declaration of 
function 

[PATCH v2 1/3] dmaengine: Add support for new feature CRC32C computations

[Rameshwar Prasad Sahu]

This patch adds support for new feature CRC32C computations in
dmaengine framework.

Signed-of-by: Rameshwar Prasad Sahu
---
 Documentation/dmaengine/provider.txt |3 +++
 drivers/dma/dmaengine.c  |2 ++
 include/linux/dmaengine.h|   13 +
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/Documentation/dmaengine/provider.txt 
b/Documentation/dmaengine/provider.txt
index 67d4ce4..2399d6f 100644
--- a/Documentation/dmaengine/provider.txt
+++ b/Documentation/dmaengine/provider.txt
@@ -224,6 +224,9 @@ Currently, the types available are:
   want to transfer a portion of uncompressed data directly to the
   display to print it

+  * DMA_CRC32C
+- The device is able to perform CRC32C computations
+
 These various types will also affect how the source and destination
 addresses change over time.

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 09479d4..8cd0365 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -865,6 +865,8 @@ int dma_async_device_register(struct dma_device *device)
!device->device_prep_dma_cyclic);
BUG_ON(dma_has_cap(DMA_INTERLEAVE, device->cap_mask) &&
!device->device_prep_interleaved_dma);
+   BUG_ON(dma_has_cap(DMA_CRC32C, device->cap_mask) &&
+   !device->device_prep_dma_crc32c);

BUG_ON(!device->device_tx_status);
BUG_ON(!device->device_issue_pending);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 7ea9184..7108d7c 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -74,6 +74,7 @@ enum dma_transaction_type {
DMA_SLAVE,
DMA_CYCLIC,
DMA_INTERLEAVE,
+   DMA_CRC32C,
 /* last transaction type for creation of the capabilities mask */
DMA_TX_TYPE_END,
 };
@@ -645,6 +646,7 @@ enum dmaengine_alignment {
  * The function takes a buffer of size buf_len. The callback function will
  * be called after period_len bytes have been transferred.
  * @device_prep_interleaved_dma: Transfer expression in a generic way.
+ * @device_prep_dma_crc32c: prepares a crc32c operation
  * @device_config: Pushes a new configuration to a channel, return 0 or an 
error
  * code
  * @device_pause: Pauses any transfer happening on a channel. Returns
@@ -727,6 +729,9 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
struct dma_chan *chan, struct dma_interleaved_template *xt,
unsigned long flags);
+   struct dma_async_tx_descriptor *(*device_prep_dma_crc32c)(
+   struct dma_chan *chan, struct scatterlist *src_sg, size_t len,
+   unsigned int seed, u8 *result, unsigned long flags);

int (*device_config)(struct dma_chan *chan,
 struct dma_slave_config *config);
@@ -824,6 +829,14 @@ static inline struct dma_async_tx_descriptor 
*dmaengine_prep_dma_sg(
src_sg, src_nents, flags);
 }

+static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_crc3c(
+   struct dma_chan *chan, struct scatterlist *src_sg,
+   size_t len, unsigned int seed, u8 *result, unsigned long flags)
+{
+   return chan->device->device_prep_dma_crc32c(chan, src_sg, len,
+   seed, result, flags);
+}
+
 static inline int dmaengine_terminate_all(struct dma_chan *chan)
 {
if (chan->device->device_terminate_all)
--
1.7.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 v2 2/3] dmaengine: xgene-dma: Add support for CRC32C computations via DMA engine

[Rameshwar Prasad Sahu]

This patch implements CRC32C support to APM X-Gene SoC DMA engine driver.
Basically we have DMA engine in SoC capable of doing CRC32C computations.

Signed-off-by: Rameshwar Prasad Sahu 
---
 drivers/dma/xgene-dma.c |  314 ---
 1 files changed, 299 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 9dfa2b0..d95dc72 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -22,6 +22,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,7 @@
 #define XGENE_DMA_RING_ENABLE  BIT(31)
 #define XGENE_DMA_RING_ID  0x08
 #define XGENE_DMA_RING_ID_SETUP(v) ((v) | BIT(31))
+#define XGENE_DMA_RING_IS_BUFPOOL  BIT(20)
 #define XGENE_DMA_RING_ID_BUF  0x0C
 #define XGENE_DMA_RING_ID_BUF_SETUP(v) (((v) << 9) | BIT(21))
 #define XGENE_DMA_RING_THRESLD0_SET1   0x30
@@ -69,6 +71,8 @@
(((u32 *)(m))[2] |= (((v) >> 8) << 5))
 #define XGENE_DMA_RING_ADDRH_SET(m, v) \
(((u32 *)(m))[3] |= ((v) >> 35))
+#define XGENE_DMA_RING_BUFMODE_SET(m)  \
+   (((u32 *)(m))[3] |= ((0x3) << 20))
 #define XGENE_DMA_RING_ACCEPTLERR_SET(m)   \
(((u32 *)(m))[3] |= BIT(19))
 #define XGENE_DMA_RING_SIZE_SET(m, v)  \
@@ -106,6 +110,7 @@
 #define XGENE_DMA_RING_INT2_MASK   0x90B0
 #define XGENE_DMA_RING_INT3_MASK   0x90B8
 #define XGENE_DMA_RING_INT4_MASK   0x90C0
+#define XGENE_DMA_CFG_RING_FQ_ASSOC0x90DC
 #define XGENE_DMA_CFG_RING_WQ_ASSOC0x90E0
 #define XGENE_DMA_ASSOC_RING_MNGR1 0x
 #define XGENE_DMA_MEM_RAM_SHUTDOWN 0xD070
@@ -127,6 +132,10 @@
 #define XGENE_DMA_DESC_LERR_POS60
 #define XGENE_DMA_DESC_BUFLEN_POS  48
 #define XGENE_DMA_DESC_HOENQ_NUM_POS   48
+#define XGENE_DMA_DESC_BD_BIT  BIT(0)
+#define XGENE_DMA_DESC_SD_BIT  BIT(1)
+#define XGENE_DMA_DESC_CRCSEED_POS 8
+#define XGENE_DMA_DESC_FPQ_NUM_POS 32
 #define XGENE_DMA_DESC_ELERR_RD(m) \
(((m) >> XGENE_DMA_DESC_ELERR_POS) & 0x3)
 #define XGENE_DMA_DESC_LERR_RD(m)  \
@@ -140,20 +149,25 @@
 /* X-Gene DMA configurable parameters defines */
 #define XGENE_DMA_RING_NUM 512
 #define XGENE_DMA_BUFNUM   0x0
+#define XGENE_DMA_BUFPOOL_BUFNUM   0x20
 #define XGENE_DMA_CPU_BUFNUM   0x18
 #define XGENE_DMA_RING_OWNER_DMA   0x03
 #define XGENE_DMA_RING_OWNER_CPU   0x0F
 #define XGENE_DMA_RING_TYPE_REGULAR0x01
+#define XGENE_DMA_RING_TYPE_BUFPOOL0x02
 #define XGENE_DMA_RING_WQ_DESC_SIZE32  /* 32 Bytes */
+#define XGENE_DMA_BUFPOOL_DESC_SIZE16  /* 16 Bytes */
 #define XGENE_DMA_RING_NUM_CONFIG  5
 #define XGENE_DMA_MAX_CHANNEL  4
 #define XGENE_DMA_XOR_CHANNEL  0
 #define XGENE_DMA_PQ_CHANNEL   1
+#define XGENE_DMA_FLYBY_CHANNEL2
 #define XGENE_DMA_MAX_BYTE_CNT 0x4000  /* 16 KB */
 #define XGENE_DMA_MAX_64B_DESC_BYTE_CNT0x14000 /* 80 KB */
 #define XGENE_DMA_MAX_XOR_SRC  5
 #define XGENE_DMA_16K_BUFFER_LEN_CODE  0x0
 #define XGENE_DMA_INVALID_LEN_CODE 0x7800ULL
+#define XGENE_DMA_MAX_FLYBY_BYTE_CNT   0x7FFF  /* (32 KB - 1) */

 /* X-Gene DMA descriptor error codes */
 #define ERR_DESC_AXI   0x01
@@ -187,9 +201,14 @@
 #define FLYBY_3SRC_XOR 0x90
 #define FLYBY_4SRC_XOR 0xA0
 #define FLYBY_5SRC_XOR 0xB0
+#define FLYBY_CRC160x10
+#define FLYBY_CRC32C   0x20
+#define FLYBY_CRC320x30
+#define FLYBY_CHECKSUM 0x40

 /* X-Gene DMA SW descriptor flags */
 #define XGENE_DMA_FLAG_64B_DESCBIT(0)
+#define XGENE_DMA_FLAG_FLYBY_ACTIVEBIT(1)

 /* Define to dump X-Gene DMA descriptor */
 #define XGENE_DMA_DESC_DUMP(desc, m)   \
@@ -206,6 +225,11 @@
 #define chan_err(chan, fmt, arg...)\
dev_err(chan->dev, "%s: " fmt, chan->name, ##arg)

+struct xgene_dma_desc16 {
+   __le64 m0;
+   __le64 m1;
+};
+
 struct xgene_dma_desc_hw {
__le64 m0;
__le64 m1;
@@ -232,6 +256,7 @@ struct xgene_dma_ring {
u16 slots;
u16 dst_ring_num;
u32 size;
+   bool is_bufpool;
void __iomem *cmd;
void __iomem *cmd_base;
dma_addr_t desc_paddr;
@@ -239,6 +264,7 @@ struct xgene_dma_ring {
enum xgene_dma_ring_cfgsize cfgsize;
union {
void *desc_vaddr;
+   struct xgene_dma_desc16 *desc16;
struct xgene_dma_desc_hw *desc_hw;
};
 };
@@ -247,6 +273,7 @@ struct xgene_dma_desc_sw {
struct xgene_dma_desc_hw desc1;
struct xgene_dma_desc_hw desc2;
u32 flags;
+   u8 

[PATCH v2 3/3] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Rameshwar Prasad Sahu]

This patch implements support for APM X-Gene SoC CRC32C h/w accelerator.
DMA engine in APM X-Gene SoC is capable of doing CRC32C computations.

Signed-off-by: Rameshwar Prasad Sahu 
---
 drivers/crypto/Kconfig|8 ++
 drivers/crypto/Makefile   |1 +
 drivers/crypto/xgene-crc32c.c |  234 +
 3 files changed, 243 insertions(+), 0 deletions(-)
 create mode 100755 drivers/crypto/xgene-crc32c.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d234719..5d90b64 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -497,4 +497,12 @@ config CRYPTO_DEV_SUN4I_SS
  To compile this driver as a module, choose M here: the module
  will be called sun4i-ss.

+config CRYPTO_DEV_XGENE_CRC32C
+   tristate "Support for APM SoC X-Gene CRC32C HW accelerator"
+   depends on XGENE_DMA
+   select CRYPTO_HASH
+   help
+ This option enables support for CRC32C offload by using
+ APM X-Gene SoC DMA engine.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..199d4e4 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_XGENE_CRC32C) += xgene-crc32c.o
diff --git a/drivers/crypto/xgene-crc32c.c b/drivers/crypto/xgene-crc32c.c
new file mode 100755
index 000..142c681
--- /dev/null
+++ b/drivers/crypto/xgene-crc32c.c
@@ -0,0 +1,234 @@
+/*
+ * Applied Micro X-Gene SoC CRC32C HW acceleration by using DMA engine
+ *
+ * Copyright (c) 2015, Applied Micro Circuits Corporation
+ * Authors: Rameshwar Prasad Sahu 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CRC32C_DIGEST_SIZE 4
+#define CRC32C_BLOCK_SIZE  1
+#define XGENE_DMA_MAX_FLYBY_SRC_CNT5
+#define XGENE_DMA_MAX_FLYBY_BYTE_CNT   0x7FFF  /* (32 KB - 1) */
+
+struct xgene_crc32c_session_ctx {
+   struct dma_chan *dchan;
+   u32 key;
+};
+
+struct xgene_crc32c_reqctx {
+   struct device *dev;
+   u32 nents;
+   u32 seed;
+};
+
+static void xgene_crc32c_callback(void *ctx)
+{
+   struct ahash_request *req = ctx;
+   struct xgene_crc32c_reqctx *reqctx = ahash_request_ctx(req);
+
+   if (req->base.complete)
+   req->base.complete(>base, 0);
+
+   dma_unmap_sg(reqctx->dev, req->src,
+reqctx->nents, DMA_TO_DEVICE);
+}
+
+static int xgene_crc32c_handle_req(struct ahash_request *req,
+  struct dma_chan *dchan)
+{
+   struct xgene_crc32c_reqctx *reqctx = ahash_request_ctx(req);
+   struct device *dev = dchan->device->dev;
+   struct dma_async_tx_descriptor *tx;
+   enum dma_ctrl_flags flags;
+   u32 nents, sg_count;
+   dma_cookie_t cookie;
+
+   if (req->nbytes > XGENE_DMA_MAX_FLYBY_BYTE_CNT) {
+   dev_err(dev, "Src len is too long %u\n", req->nbytes);
+   return -EINVAL;
+   }
+
+   nents = sg_nents(req->src);
+   sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
+   if (!sg_count) {
+   dev_err(dev, "Failed to map src sg");
+   return -EIO;
+   }
+
+   if (sg_count > XGENE_DMA_MAX_FLYBY_SRC_CNT) {
+   dev_err(dev, "Unsupported src sg count %d\n", sg_count);
+   goto err;
+   }
+
+   flags = DMA_CTRL_ACK;
+
+   tx = dmaengine_prep_dma_crc3c(dchan, req->src, req->nbytes,
+ reqctx->seed, req->result, flags);
+   if (!tx)
+   goto err;
+
+   /* Set callback parameters */
+   reqctx->dev = dev;
+   reqctx->nents = nents;
+   tx->callback_param = req;
+   tx->callback = xgene_crc32c_callback;
+
+   cookie = tx->tx_submit(tx);
+   if (dma_submit_error(cookie)) {
+   dev_err(dev, "Failed to submit descriptor\n");
+   goto err;
+   }
+
+   dma_async_issue_pending(dchan);
+
+   return -EINPROGRESS;
+
+err:
+   dma_unmap_sg(dev, req->src, nents, DMA_TO_DEVICE);
+   return -EINVAL;
+}
+

Re: [PATCH 1/7] A couple of generated files

[Sandy Harris]

On Sat, Nov 7, 2015 at 12:01 PM, Jason Cooper  wrote:
> On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
>> Signed-off-by: Sandy Harris 
>> ---
>>  .gitignore | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index fd3a355..dd80bfd 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -112,3 +112,6 @@ all.config
>>
>>  # Kdevelop4
>>  *.kdev4
>> +
>> +certs/x509_certificate_list
>> +scripts/gen_random
>
> Is there a .gitignore file in scripts/ ?
>

Yes, though I wasn't aware of that.
I guess gen_random should be there instead of in the global file.
--
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/7] A couple of generated files

[Sandy Harris]

Jason Cooper  wrote:

> I know we talked  about this series offlist, but we need to fill in
> folks who are seeing it for the first time.  Usually, this is done with
> a coverletter (--coverletter for git format-patch).

Yes, your help plus the O'Reilly book got me using git without
too many errors, but I'm still getting things wrong & missing
the cover letter was one.

> No need to resend
> before receiving feedback, but would you mind replying with a
> description of the problem you're attempting to solve and how the series
> solves it?

There are two groups of changes, each controlled by a config
variable. Default for both is 'n'.

CONFIG_RANDOM_INIT: initialise the pools with data from
/dev/urandom on the machine that compiles the kernel.
Comments for the generator program scripts/gen_random.c
have details.

The main change in random.c is adding conditionals
to make it use the random data if CONFIG_RANDOM_INIT
is set. There is also a trivial fix updating a reference to an
obsoleted in a comment, and I added some sanity-check
#if tests for odd #define parameter values.

This is a fairly simple change. I do not think it needs a config
variable; it should just be the default. However I put it under
config control for testing.

CONFIG_RANDOM_GCM controls a much larger and
less clearly desirable set of changes. It switches
compilation between random.c and and a heavily
modified version random_gcm.c

This uses the hash from AES-GCM instead of SHA-1,
and that allows a lot of other changes. The main
design goal was to decouple the two output pools
so that heavy use of the nonblocking pool cannot
deplete entropy in the input pool. The nonblocking
pool usually rekeys from the blocking pool instead.
random_gcm.c has extensive comments on both
the rationale for this approach & the details of my
implementation.

random_gcm.c is not close to being a finished
product, in particular my code is not yet well
integrated with existing driver code.

Most of the code was developed and has been
fairly well tested outside the kernel.
Test program is at:
https://github.com/sandy-harris/random.test

I just dropped a large chunk of that code into
a copy of random.c, made modifications to
make the style match better & to get it to
compile in the kernel context, then deleted
a few chunks of existing driver code and
replaced them with calls to my stuff.

Proper integration would involve both
replacing more of the existing code with
new and moving a few important bits of
the existing code into some of my functions.
In particular, my stuff does not yet block
in the right places.
--
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 7/7] Create generated/random_init.h, used by random driver

[kbuild test robot]

Hi Sandy,

[auto build test ERROR on: char-misc/char-misc-testing]
[also build test ERROR on: v4.3 next-20151106]

url:
https://github.com/0day-ci/linux/commits/Sandy-Harris/A-couple-of-generated-files/20151107-223540
config: sh-allyesconfig (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=sh 

All errors (new ones prefixed by >>):

>> scripts/gen_random.c:61:19: fatal error: stdio.h: No such file or directory
   compilation terminated.
   make[2]: *** [scripts/gen_random] Error 1
   :1229:2: warning: #warning syscall sched_setattr not implemented 
[-Wcpp]
   :1232:2: warning: #warning syscall sched_getattr not implemented 
[-Wcpp]
   :1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
   :1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
   :1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
   :1244:2: warning: #warning syscall memfd_create not implemented 
[-Wcpp]
   :1247:2: warning: #warning syscall bpf not implemented [-Wcpp]
   :1250:2: warning: #warning syscall execveat not implemented [-Wcpp]
   :1298:2: warning: #warning syscall userfaultfd not implemented [-Wcpp]
   :1301:2: warning: #warning syscall membarrier not implemented [-Wcpp]
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +61 scripts/gen_random.c

06038f35 Sandy Harris 2015-11-07  45   * This is certainly done early enough 
and the data is random
06038f35 Sandy Harris 2015-11-07  46   * enough, but it is not necessarily 
secret enough.
06038f35 Sandy Harris 2015-11-07  47   *
06038f35 Sandy Harris 2015-11-07  48   * In some cases -- for example, a 
firewall machine that compiles
06038f35 Sandy Harris 2015-11-07  49   * its own kernel -- this alone might be 
enough to ensure secure
06038f35 Sandy Harris 2015-11-07  50   * initialisation, since only an enemy 
who already has root could
06038f35 Sandy Harris 2015-11-07  51   * discover this data. Of course even in 
those cases it should not
06038f35 Sandy Harris 2015-11-07  52   * be used alone, only as one layer of a 
defense in depth.
06038f35 Sandy Harris 2015-11-07  53   *
06038f35 Sandy Harris 2015-11-07  54   * In other cases -- a kernel that is 
compiled once then used in
06038f35 Sandy Harris 2015-11-07  55   * a Linux distro or installed on many 
devices -- this is likely
06038f35 Sandy Harris 2015-11-07  56   * of very little value. It complicates 
an attack somewhat, but
06038f35 Sandy Harris 2015-11-07  57   * it clearly will not stop a serious 
attacker and may not even
06038f35 Sandy Harris 2015-11-07  58   * slow them down much.
06038f35 Sandy Harris 2015-11-07  59   */
06038f35 Sandy Harris 2015-11-07  60  
06038f35 Sandy Harris 2015-11-07 @61  #include 
06038f35 Sandy Harris 2015-11-07  62  #include 
06038f35 Sandy Harris 2015-11-07  63  #include 
06038f35 Sandy Harris 2015-11-07  64  #include 
06038f35 Sandy Harris 2015-11-07  65  #include 
06038f35 Sandy Harris 2015-11-07  66  #include 
06038f35 Sandy Harris 2015-11-07  67  
06038f35 Sandy Harris 2015-11-07  68  /*
06038f35 Sandy Harris 2015-11-07  69   * Configuration information

:: The code at line 61 was first introduced by commit
:: 06038f35641185897feb14917d89d03fab1710ba Produces 
generated/random_init.h for random driver

:: TO: Sandy Harris <sandyinch...@gmail.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: Binary data

Re: [PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

[Jason Cooper]

On Sat, Nov 07, 2015 at 09:30:38AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  drivers/char/random.c | 50 ++
>  1 file changed, 46 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d0da5d8..e222e0f 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -231,7 +231,7 @@
>   * not be attributed to the Phil, Colin, or any of authors of PGP.
>   *
>   * Further background information on this topic may be obtained from
> - * RFC 1750, "Randomness Recommendations for Security", by Donald
> + * RFC 4086, "Randomness Requirements for Security", by Donald

I'm pretty sure you already sent this hunk separately.  Please remove it
from the next version.

thx,

Jason.

>   * Eastlake, Steve Crocker, and Jeff Schiller.
>   */
>  
> @@ -275,13 +275,19 @@
>  /*
>   * Configuration information
>   */
> +#ifdef CONFIG_RANDOM_INIT
> +
> +#include 
> +
> +#else
>  #define INPUT_POOL_SHIFT 12
>  #define INPUT_POOL_WORDS (1 << (INPUT_POOL_SHIFT-5))
>  #define OUTPUT_POOL_SHIFT10
>  #define OUTPUT_POOL_WORDS(1 << (OUTPUT_POOL_SHIFT-5))
> -#define SEC_XFER_SIZE512
> -#define EXTRACT_SIZE 10
> +#endif
>  
> +#define EXTRACT_SIZE 10
> +#define SEC_XFER_SIZE512
>  #define DEBUG_RANDOM_BOOT 0
>  
>  #define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
> @@ -296,6 +302,27 @@
>  #define ENTROPY_SHIFT 3
>  #define ENTROPY_BITS(r) ((r)->entropy_count >> ENTROPY_SHIFT)
>  
> +/* sanity checks */
> +
> +#if ((ENTROPY_SHIFT+INPUT_POOL_SHIFT) >= 16)
> +#ifndef CONFIG_64BIT
> +#error *_SHIFT values problematic for credit_entropy_bits()
> +#endif
> +#endif
> +
> +#if ((INPUT_POOL_WORDS%16) || (OUTPUT_POOL_WORDS%16))
> +#error Pool size not divisible by 16, which code assumes
> +#endif
> +
> +#if (INPUT_POOL_WORDS < 32)
> +#error Input pool less than a quarter of default size
> +#endif
> +
> +#if (INPUT_POOL_WORDS < OUTPUT_POOL_WORDS)
> +#error Strange configuration, input pool smalller than output
> +#endif
> +
> +
>  /*
>   * The minimum number of bits of entropy before we wake up a read on
>   * /dev/random.  Should be enough to do a significant reseed.
> @@ -442,16 +469,23 @@ struct entropy_store {
>  };
>  
>  static void push_to_pool(struct work_struct *work);
> +
> +#ifndef CONFIG_RANDOM_INIT
>  static __u32 input_pool_data[INPUT_POOL_WORDS];
>  static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
>  static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS];
> +#endif
>  
>  static struct entropy_store input_pool = {
>   .poolinfo = _table[0],
>   .name = "input",
>   .limit = 1,
>   .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
> - .pool = input_pool_data
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools,
> +#else
> + .pool = input_pool_data,
> +#endif
>  };
>  
>  static struct entropy_store blocking_pool = {
> @@ -460,7 +494,11 @@ static struct entropy_store blocking_pool = {
>   .limit = 1,
>   .pull = _pool,
>   .lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock),
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools + INPUT_POOL_WORDS,
> +#else
>   .pool = blocking_pool_data,
> +#endif
>   .push_work = __WORK_INITIALIZER(blocking_pool.push_work,
>   push_to_pool),
>  };
> @@ -470,7 +508,11 @@ static struct entropy_store nonblocking_pool = {
>   .name = "nonblocking",
>   .pull = _pool,
>   .lock = __SPIN_LOCK_UNLOCKED(nonblocking_pool.lock),
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools + INPUT_POOL_WORDS + OUTPUT_POOL_WORDS,
> +#else
>   .pool = nonblocking_pool_data,
> +#endif
>   .push_work = __WORK_INITIALIZER(nonblocking_pool.push_work,
>   push_to_pool),
>  };
> -- 
> 2.5.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: [PATCH 1/7] A couple of generated files

[Jason Cooper]

On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  .gitignore | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index fd3a355..dd80bfd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -112,3 +112,6 @@ all.config
>  
>  # Kdevelop4
>  *.kdev4
> +
> +certs/x509_certificate_list
> +scripts/gen_random

Is there a .gitignore file in scripts/ ?

thx,

Jason.
--
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 2/2] ath9k: export HW random number generator

[Nick Kossifidis]

Hello all,

That was partially my intention too when I submitted
2aa56cca3571fd08c0c38f3e2d4bb0bfb3def3c5 which mixes FFT measurements
to the entropy pool without providing any estimation on entropy
(entropy estimation is the wrong approach, read the papers on fortuna
for more information on that). I believe that this approach is better
than mine because FFT data is too much (high throughput) and may have
a negative impact on the pool when mixed like this (even without the
entropy count) so Kale please revert my patch also (I was about to
submit a request for reverting it and writing something similar when
this thread came up). I believe that exporting the card as a hw rng
and letting a userspace helper do the whitening and the post
processing is the proper approach.

The idea behind exposing a device as a hw random number generator is
not that it's output is ready to be used. It's just an entropy source.
Almost every entropy source has some bias and no it's not always
expected from a hw rng to do whitening on it's own, it's actually more
secure to get the raw data and perform the whitening yourself because
if what you get from the hw rng is already being post-processed then
there is no way to know if someone has hidden a backdoor there (that
was the big discussion about Intel's RDRAND and the possibility of an
NSA backdoor in there -it could just be AES on CTR mode with a known
key/iv-, we get whitened data so we don't know if we can trust them).
A userspace helper is needed for proper whitening and statistical
analysis (and no fips is not enough, try dieharder and ent and then go
for more custom stuff) because we should keep the kernel clean. That's
what rngd was supposed to do (do the whitening on userspace and then
submit it back to the kernel's pool).

What's wrong with exporting the atheros cards as a hw random number
generator ? Is the recently added jitter RNG (currently exposed as an
RNG through the CryptoAPI) any better ? Does it have stronger entropy
claims ? It just passes the statistical tests, it doesn't mean it has
good "randomness" (let me remind you hpa's comments on HAVEGEd on
LinuxCon 2012), a CPU is a deterministic system, the fact that there
are many parameters on this system -not on all CPUs by the way, not
everything out there is a cisc with branch prediction etc- turns it to
a very complex system to analyze (chaotic behavior) which is good
enough for what we want but it doesn't compare to an actual physical
phenomenon such as E/M noise (btw a type of "jitter" is already mixed
on the /dev/random's entropy pool since 2013 when I submitted this
http://lkml.iu.edu/hypermail/linux/kernel/1211.2/00863.html -again
with no entropy estimation and only by using timers- but it's not
random in any way, it's just "too complicated to analyze" -that's what
hpa also told about HAVEGEd and I totally agree with him-).

The truth is that it's very hard to get good quality entropy in a way
that's guaranteed e.g. even in the atheros's case an attacker can bias
the RNG by hitting the card with a sine wave signal on the IF, only
quantum phenomena such as photon detection -e.g. through radioactive
decay- or even better measurements of the void based on Heisenberg's
uncertainty principle can be truly classified as random and not
always, we still have Bell's correlations such as entanglement -so
e.g. something that seems random to us locally might not be random to
the attacker, our system might be entangled with the attacker's
system-. Even the current hw rngs supported by the framework might
provide non-random data in case of hw failure (think of an RNG based
on avalanche effect with a broken diode), that's why we should always
do extensive post-processing and kernel is not the place for that.

Some more comments here: I see people trusting HAVEGEd and entropy
from sound cards, video cards etc and even provide some "proof" about
how good that is. It's all wrong ! First of all there is no definition
of randomness, if we could define randomness it wouldn't be random any
more (we 'd have some information about it), there is only the
uncertainty principle. Second you can't have claims on entropy bounds
because such systems behave differently under different circumstances
or different configurations. HAVEGEd for example gathers entropy based
on the assumption that we have context switching and a complex CPU so
that it's too complicated to guess what's running on the system (again
no strong claims on entropy bounds it's just "it's messy enough, it
passes the tests, so it's ok"). Try running it on a real-time system
with a single process and you can say goodbye to any entropy claims.
Sound cards ? If you don't properly configure your sound card (even in
the case of having nothing connected on the mic, just gathering
thermal noise from the resistor) you 'll end up with no entropy at all
! Most sound cards have a noise cancellation system or they have a
volume threshold so they won't give anything below that (all 

Re: [PATCH 2/2] ath9k: export HW random number generator

[Nick Kossifidis]

Just a question to the Qualcomm devs: You are reading the TEST_DAC
register after switching the PHY to test mode or something. How would
that affect the card's behavior (e.g. if it gets called very
frequently) ? Is it possible to have packet loss or disconnections
because of that ? Also I notice that you read the register twice ?
What's the format of the data you get ?

My approach right now is to get FFT samples from the spectral scan
feature on "background" mode (when the card is scanning) so I get much
more throughput out of that (it's not MMIO, it's dma) and it's more
passive because it's data the card already gathers as part of its
radar detection loop. However I grab the data through debugfs (through
the current interface we have for spectral scan), I'd like to expose
this as a hw rng but I 'm still looking on the proper way of doing it
without having to buffer all this data of put them somewhere until a
consumer comes up. Maybe we could combine the two, provide high
throughput FFT samples (the raw data, without the formatting) when a
spectral scan is happening and when there are no spectral data -and if
your approach doesn't affect the card's operation- we could use that
for backup.


2015-11-07 17:39 GMT-06:00 Nick Kossifidis :
> Hello all,
>
> That was partially my intention too when I submitted
> 2aa56cca3571fd08c0c38f3e2d4bb0bfb3def3c5 which mixes FFT measurements
> to the entropy pool without providing any estimation on entropy
> (entropy estimation is the wrong approach, read the papers on fortuna
> for more information on that). I believe that this approach is better
> than mine because FFT data is too much (high throughput) and may have
> a negative impact on the pool when mixed like this (even without the
> entropy count) so Kale please revert my patch also (I was about to
> submit a request for reverting it and writing something similar when
> this thread came up). I believe that exporting the card as a hw rng
> and letting a userspace helper do the whitening and the post
> processing is the proper approach.
>
> The idea behind exposing a device as a hw random number generator is
> not that it's output is ready to be used. It's just an entropy source.
> Almost every entropy source has some bias and no it's not always
> expected from a hw rng to do whitening on it's own, it's actually more
> secure to get the raw data and perform the whitening yourself because
> if what you get from the hw rng is already being post-processed then
> there is no way to know if someone has hidden a backdoor there (that
> was the big discussion about Intel's RDRAND and the possibility of an
> NSA backdoor in there -it could just be AES on CTR mode with a known
> key/iv-, we get whitened data so we don't know if we can trust them).
> A userspace helper is needed for proper whitening and statistical
> analysis (and no fips is not enough, try dieharder and ent and then go
> for more custom stuff) because we should keep the kernel clean. That's
> what rngd was supposed to do (do the whitening on userspace and then
> submit it back to the kernel's pool).
>
> What's wrong with exporting the atheros cards as a hw random number
> generator ? Is the recently added jitter RNG (currently exposed as an
> RNG through the CryptoAPI) any better ? Does it have stronger entropy
> claims ? It just passes the statistical tests, it doesn't mean it has
> good "randomness" (let me remind you hpa's comments on HAVEGEd on
> LinuxCon 2012), a CPU is a deterministic system, the fact that there
> are many parameters on this system -not on all CPUs by the way, not
> everything out there is a cisc with branch prediction etc- turns it to
> a very complex system to analyze (chaotic behavior) which is good
> enough for what we want but it doesn't compare to an actual physical
> phenomenon such as E/M noise (btw a type of "jitter" is already mixed
> on the /dev/random's entropy pool since 2013 when I submitted this
> http://lkml.iu.edu/hypermail/linux/kernel/1211.2/00863.html -again
> with no entropy estimation and only by using timers- but it's not
> random in any way, it's just "too complicated to analyze" -that's what
> hpa also told about HAVEGEd and I totally agree with him-).
>
> The truth is that it's very hard to get good quality entropy in a way
> that's guaranteed e.g. even in the atheros's case an attacker can bias
> the RNG by hitting the card with a sine wave signal on the IF, only
> quantum phenomena such as photon detection -e.g. through radioactive
> decay- or even better measurements of the void based on Heisenberg's
> uncertainty principle can be truly classified as random and not
> always, we still have Bell's correlations such as entanglement -so
> e.g. something that seems random to us locally might not be random to
> the attacker, our system might be entangled with the attacker's
> system-. Even the current hw rngs supported by the framework might
> provide non-random data in case of hw failure 

Re: [PATCH v2 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Heiko Stuebner]

Hi Zain,

looks like my comment on v1 came later than your v2 submission,
so here it is again :-)

Am Freitag, 6. November 2015, 09:17:21 schrieb Zain Wang:
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
> 

[...]

> diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
> b/drivers/crypto/rockchip/rk3288_crypto.c
> new file mode 100644
> index 000..c2a419b
> --- /dev/null
> +++ b/drivers/crypto/rockchip/rk3288_crypto.c

[...]

> +static int rk_crypto_probe(struct platform_device *pdev)
> +{
> + int err = 0;
> + struct resource *res;
> + struct device *dev = >dev;
> + struct crypto_info_t *crypto_info;
> +

rk3288 chromebooks use the crypto-engine to validate the boot images and
seem to leave it in a half-on state. This results in an irq pending
during probe and thus a null-pointer dereference in the irq-handler, as
it runs before the crypto-device is fully initialized.

resetting the crypto block, successfull fixed that issue, so I did the
following change:

---
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 121b6d5..e978fb2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -182,6 +182,8 @@
  "hclk",
  "sclk",
  "apb_pclk";
+   resets = < SRST_CRYPTO>;
+   reset-names = "crypto";
status = "okay";
};
 
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
b/drivers/crypto/rockchip/rk3288_crypto.c
index 02830f2..2245d3d 100644
--- a/drivers/crypto/rockchip/rk3288_crypto.c
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct crypto_info_t *crypto_p;
 
@@ -266,6 +267,15 @@ static int rk_crypto_probe(struct platform_device *pdev)
struct resource *res;
struct device *dev = >dev;
struct crypto_info_t *crypto_info;
+   struct reset_control *rst;
+
+   /* reset the block to remove any pending actions */
+   rst = devm_reset_control_get(dev, "crypto");
+   if (!IS_ERR(rst)) {
+   reset_control_assert(rst);
+   usleep_range(10, 20);
+   reset_control_deassert(rst);
+   }
 
crypto_info = devm_kzalloc(>dev,
sizeof(*crypto_info), GFP_KERNEL);
---


> + crypto_info = devm_kzalloc(>dev,
> +sizeof(*crypto_info), GFP_KERNEL);
> + if (!crypto_info)
> + return -ENOMEM;
> +
> + spin_lock_init(_info->lock);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + crypto_info->reg = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(crypto_info->reg)) {
> + err = PTR_ERR(crypto_info->reg);
> + goto err_ioremap;
> + }
> +
> + crypto_info->aclk = devm_clk_get(>dev, "aclk");
> + if (IS_ERR(crypto_info->aclk)) {
> + err = PTR_ERR(crypto_info->aclk);
> + goto err_ioremap;
> + }
> +
> + crypto_info->hclk = devm_clk_get(>dev, "hclk");
> + if (IS_ERR(crypto_info->hclk)) {
> + err = PTR_ERR(crypto_info->hclk);
> + goto err_ioremap;
> + }
> +
> + crypto_info->sclk = devm_clk_get(>dev, "sclk");
> + if (IS_ERR(crypto_info->sclk)) {
> + err = PTR_ERR(crypto_info->sclk);
> + goto err_ioremap;
> + }
> +
> + crypto_info->dmaclk = devm_clk_get(>dev, "apb_pclk");
> + if (IS_ERR(crypto_info->dmaclk)) {
> + err = PTR_ERR(crypto_info->dmaclk);
> + goto err_ioremap;
> + }
> +
> + crypto_info->irq = platform_get_irq(pdev, 0);
> + if (crypto_info->irq < 0) {
> + dev_warn(crypto_info->dev,
> +  "control Interrupt is not available.\n");
> + err = crypto_info->irq;
> + goto err_ioremap;
> + }
> +
> + err = devm_request_irq(>dev, crypto_info->irq, crypto_irq_handle,
> +IRQF_SHARED, "rk-crypto", pdev);
> +
> + if (err) {
> + dev_err(crypto_info->dev, "irq request failed.\n");
> + goto err_ioremap;
> + }
> +
> + crypto_info->dev = >dev;
> + platform_set_drvdata(pdev, crypto_info);
> + crypto_p = crypto_info;
> +
> + tasklet_init(_info->crypto_tasklet,
> +  rk_crypto_tasklet_cb, (unsigned long)crypto_info);
> + crypto_init_queue(_info->queue, 50);
> +
> + crypto_info->enable_clk = rk_crypto_enable_clk;
> + crypto_info->disable_clk = rk_crypto_disable_clk;
> + crypto_info->load_data = rk_load_data;
> + crypto_info->unload_data = rk_unload_data;
> +
> + err = rk_crypto_register();
> + if (err) {