Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Thu, Dec 15, 2016 at 12:47:16AM +0530, PrasannaKumar Muralidharan wrote:
> Should there be a mandate that driver will be accepted only when it
> passes 'rngtest'. This will make sure that prng drivers won't get
> added in future.

You cannot use software to distinguish between a PRNG and an HRNG.
We can only rely on the veracity of the documentation.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Thu, Dec 15, 2016 at 12:47:16AM +0530, PrasannaKumar Muralidharan wrote:
> Should there be a mandate that driver will be accepted only when it
> passes 'rngtest'. This will make sure that prng drivers won't get
> added in future.

You cannot use software to distinguish between a PRNG and an HRNG.
We can only rely on the veracity of the documentation.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

>> I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.

Even if both the solutions could not be adopted I think there must be
a way for applications to use similar API to get true rng or prng.
Given the case that no user complained about prng data when using
/dev/hwrng is it safe to assume that the random data generated is
acceptable for users? If so, the drivers can be left without any
modification.

Should there be a mandate that driver will be accepted only when it
passes 'rngtest'. This will make sure that prng drivers won't get
added in future.

Regards,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

>> I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.

Even if both the solutions could not be adopted I think there must be
a way for applications to use similar API to get true rng or prng.
Given the case that no user complained about prng data when using
/dev/hwrng is it safe to assume that the random data generated is
acceptable for users? If so, the drivers can be left without any
modification.

Should there be a mandate that driver will be accepted only when it
passes 'rngtest'. This will make sure that prng drivers won't get
added in future.

Regards,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Wed, Dec 14, 2016 at 01:05:51PM +0800, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
> >
> > I have found two solutions:
> 
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
> 

But algif_rng is not accessible from user space without any coding.
So no easy "random" data with some cat /dev/.

Clearly users of the 3 already intree hw_random PRNG will see that like a 
regresion.

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Wed, Dec 14, 2016 at 01:05:51PM +0800, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
> >
> > I have found two solutions:
> 
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
> 

But algif_rng is not accessible from user space without any coding.
So no easy "random" data with some cat /dev/.

Clearly users of the 3 already intree hw_random PRNG will see that like a 
regresion.

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
>
> I have found two solutions:

No we already have algif_rng so let's not confuse things even
further by making hwrng take PRNGs.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
>
> I have found two solutions:

No we already have algif_rng so let's not confuse things even
further by making hwrng take PRNGs.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Tue, Dec 13, 2016 at 08:53:54PM +0530, PrasannaKumar Muralidharan wrote:
> > What do you think about those two solutions ?
> 
> I prefer the second solution's idea of using two files (/dev/hwrng and
> /dev/hwprng). Upon having a quick glance it looks like (based on
> current_rng == prng check) that your current implementation allows
> only one rng device to be in use at a time. It would be better to have
> both usable at the same time. So applications that need pseudo random
> data at high speed can use /dev/prng while applications that require
> true random number can use /dev/rng. Please feel free to correct if my
> understanding of the code is incorrect. Along with this change I think
> changing the algif_rng to use this code if this solution is going to
> be used.
> 

No, there could be both device at the same time.

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Tue, Dec 13, 2016 at 08:53:54PM +0530, PrasannaKumar Muralidharan wrote:
> > What do you think about those two solutions ?
> 
> I prefer the second solution's idea of using two files (/dev/hwrng and
> /dev/hwprng). Upon having a quick glance it looks like (based on
> current_rng == prng check) that your current implementation allows
> only one rng device to be in use at a time. It would be better to have
> both usable at the same time. So applications that need pseudo random
> data at high speed can use /dev/prng while applications that require
> true random number can use /dev/rng. Please feel free to correct if my
> understanding of the code is incorrect. Along with this change I think
> changing the algif_rng to use this code if this solution is going to
> be used.
> 

No, there could be both device at the same time.

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

> What do you think about those two solutions ?

I prefer the second solution's idea of using two files (/dev/hwrng and
/dev/hwprng). Upon having a quick glance it looks like (based on
current_rng == prng check) that your current implementation allows
only one rng device to be in use at a time. It would be better to have
both usable at the same time. So applications that need pseudo random
data at high speed can use /dev/prng while applications that require
true random number can use /dev/rng. Please feel free to correct if my
understanding of the code is incorrect. Along with this change I think
changing the algif_rng to use this code if this solution is going to
be used.

Regards,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

> What do you think about those two solutions ?

I prefer the second solution's idea of using two files (/dev/hwrng and
/dev/hwprng). Upon having a quick glance it looks like (based on
current_rng == prng check) that your current implementation allows
only one rng device to be in use at a time. It would be better to have
both usable at the same time. So applications that need pseudo random
data at high speed can use /dev/prng while applications that require
true random number can use /dev/rng. Please feel free to correct if my
understanding of the code is incorrect. Along with this change I think
changing the algif_rng to use this code if this solution is going to
be used.

Regards,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> > 
> > So I must expose it as a crypto_rng ?
> 
> If it is to be exposed at all then algif_rng would be the best
> place.
> 
> > Could you explain why PRNG must not be used as hw_random ?
> 
> The hwrng interface was always meant to be an interface for real
> hardware random number generators.  People rely on that so we
> should not provide bogus entropy sources through this interface.
> 
> Cheers,

I have found two solutions:

The simplier is to add an attribute isprng to hwrng like that:
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -150,7 +150,8 @@ static int hwrng_init(struct hwrng *rng)
reinit_completion(>cleanup_done);
 
 skip_init:
-   add_early_randomness(rng);
+   if (!rng->isprng)
+   add_early_randomness(rng);
 
current_quality = rng->quality ? : default_quality;
if (current_quality > 1024)
@@ -158,7 +159,7 @@ static int hwrng_init(struct hwrng *rng)
 
if (current_quality == 0 && hwrng_fill)
kthread_stop(hwrng_fill);
-   if (current_quality > 0 && !hwrng_fill)
+   if (current_quality > 0 && !hwrng_fill && !rng->isprng)
start_khwrngd();
 
return 0;
@@ -439,7 +440,7 @@ int hwrng_register(struct hwrng *rng)
}
list_add_tail(>list, _list);
 
-   if (old_rng && !rng->init) {
+   if (old_rng && !rng->init && !rng->isprng) {
/*
 * Use a new device's input to add some randomness to
 * the system.  If this rng device isn't going to be
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 34a0dc1..5a5b8dc 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -50,6 +50,7 @@ struct hwrng {
struct list_head list;
struct kref ref;
struct completion cleanup_done;
+   bool isprng;
 };


With that, we still could register prng, but they dont provide any entropy.
An optional Kconfig/"module parameter" could still be added for people still 
wanting this old behavour.


The other solution is to "duplicate" /dev/hwrng to /dev/hwprng like that:
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -24,8 +24,11 @@
 #include 
 
 #define RNG_MODULE_NAME"hw_random"
+#define PRNG_MODULE_NAME   "hw_prng"
+#define HWPRNG_MINOR   185 /* not official */
 
 static struct hwrng *current_rng;
+static struct hwrng *current_prng;
 static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
 /* Protects rng_list and current_rng */
@@ -44,7 +47,7 @@ module_param(default_quality, ushort, 0644);
 MODULE_PARM_DESC(default_quality,
 "default entropy content of hwrng per mill");
 
-static void drop_current_rng(void);
+static void drop_current_rng(bool prng);
 static int hwrng_init(struct hwrng *rng);
 static void start_khwrngd(void);
 
@@ -56,6 +59,14 @@ static size_t rng_buffer_size(void)
return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
 }
 
+static bool is_current_xrng(struct hwrng *rng)
+{
+   if (rng->isprng)
+   return (rng == current_prng);
+   else
+   return (rng == current_rng);
+}
+
 static void add_early_randomness(struct hwrng *rng)
 {
int bytes_read;
@@ -88,32 +99,46 @@ static int set_current_rng(struct hwrng *rng)
if (err)
return err;
 
-   drop_current_rng();
-   current_rng = rng;
+   drop_current_rng(rng->isprng);
+   if (rng->isprng)
+   current_prng = rng;
+   else
+   current_rng = rng;
 
return 0;
 }
 
-static void drop_current_rng(void)
+static void drop_current_rng(bool prng)
 {
BUG_ON(!mutex_is_locked(_mutex));
-   if (!current_rng)
-   return;
-
-   /* decrease last reference for triggering the cleanup */
-   kref_put(_rng->ref, cleanup_rng);
-   current_rng = NULL;
+   if (prng) {
+   if (!current_prng)
+   return;
+   /* decrease last reference for triggering the cleanup */
+   kref_put(_prng->ref, cleanup_rng);
+   current_prng = NULL;
+   } else {
+   if (!current_rng)
+   return;
+   /* decrease last reference for triggering the cleanup */
+   kref_put(_rng->ref, cleanup_rng);
+   current_rng = NULL;
+   }
 }
 
 /* Returns ERR_PTR(), NULL or refcounted hwrng */
-static struct hwrng *get_current_rng(void)
+static struct hwrng *get_current_rng(bool prng)
 {
struct hwrng *rng;
 
if (mutex_lock_interruptible(_mutex))
return ERR_PTR(-ERESTARTSYS);
 
-   rng = current_rng;
+   if (prng)
+   rng = current_prng;
+   else
+   rng = current_rng;
+
if (rng)

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> > 
> > So I must expose it as a crypto_rng ?
> 
> If it is to be exposed at all then algif_rng would be the best
> place.
> 
> > Could you explain why PRNG must not be used as hw_random ?
> 
> The hwrng interface was always meant to be an interface for real
> hardware random number generators.  People rely on that so we
> should not provide bogus entropy sources through this interface.
> 
> Cheers,

I have found two solutions:

The simplier is to add an attribute isprng to hwrng like that:
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -150,7 +150,8 @@ static int hwrng_init(struct hwrng *rng)
reinit_completion(>cleanup_done);
 
 skip_init:
-   add_early_randomness(rng);
+   if (!rng->isprng)
+   add_early_randomness(rng);
 
current_quality = rng->quality ? : default_quality;
if (current_quality > 1024)
@@ -158,7 +159,7 @@ static int hwrng_init(struct hwrng *rng)
 
if (current_quality == 0 && hwrng_fill)
kthread_stop(hwrng_fill);
-   if (current_quality > 0 && !hwrng_fill)
+   if (current_quality > 0 && !hwrng_fill && !rng->isprng)
start_khwrngd();
 
return 0;
@@ -439,7 +440,7 @@ int hwrng_register(struct hwrng *rng)
}
list_add_tail(>list, _list);
 
-   if (old_rng && !rng->init) {
+   if (old_rng && !rng->init && !rng->isprng) {
/*
 * Use a new device's input to add some randomness to
 * the system.  If this rng device isn't going to be
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 34a0dc1..5a5b8dc 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -50,6 +50,7 @@ struct hwrng {
struct list_head list;
struct kref ref;
struct completion cleanup_done;
+   bool isprng;
 };


With that, we still could register prng, but they dont provide any entropy.
An optional Kconfig/"module parameter" could still be added for people still 
wanting this old behavour.


The other solution is to "duplicate" /dev/hwrng to /dev/hwprng like that:
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -24,8 +24,11 @@
 #include 
 
 #define RNG_MODULE_NAME"hw_random"
+#define PRNG_MODULE_NAME   "hw_prng"
+#define HWPRNG_MINOR   185 /* not official */
 
 static struct hwrng *current_rng;
+static struct hwrng *current_prng;
 static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
 /* Protects rng_list and current_rng */
@@ -44,7 +47,7 @@ module_param(default_quality, ushort, 0644);
 MODULE_PARM_DESC(default_quality,
 "default entropy content of hwrng per mill");
 
-static void drop_current_rng(void);
+static void drop_current_rng(bool prng);
 static int hwrng_init(struct hwrng *rng);
 static void start_khwrngd(void);
 
@@ -56,6 +59,14 @@ static size_t rng_buffer_size(void)
return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
 }
 
+static bool is_current_xrng(struct hwrng *rng)
+{
+   if (rng->isprng)
+   return (rng == current_prng);
+   else
+   return (rng == current_rng);
+}
+
 static void add_early_randomness(struct hwrng *rng)
 {
int bytes_read;
@@ -88,32 +99,46 @@ static int set_current_rng(struct hwrng *rng)
if (err)
return err;
 
-   drop_current_rng();
-   current_rng = rng;
+   drop_current_rng(rng->isprng);
+   if (rng->isprng)
+   current_prng = rng;
+   else
+   current_rng = rng;
 
return 0;
 }
 
-static void drop_current_rng(void)
+static void drop_current_rng(bool prng)
 {
BUG_ON(!mutex_is_locked(_mutex));
-   if (!current_rng)
-   return;
-
-   /* decrease last reference for triggering the cleanup */
-   kref_put(_rng->ref, cleanup_rng);
-   current_rng = NULL;
+   if (prng) {
+   if (!current_prng)
+   return;
+   /* decrease last reference for triggering the cleanup */
+   kref_put(_prng->ref, cleanup_rng);
+   current_prng = NULL;
+   } else {
+   if (!current_rng)
+   return;
+   /* decrease last reference for triggering the cleanup */
+   kref_put(_rng->ref, cleanup_rng);
+   current_rng = NULL;
+   }
 }
 
 /* Returns ERR_PTR(), NULL or refcounted hwrng */
-static struct hwrng *get_current_rng(void)
+static struct hwrng *get_current_rng(bool prng)
 {
struct hwrng *rng;
 
if (mutex_lock_interruptible(_mutex))
return ERR_PTR(-ERESTARTSYS);
 
-   rng = current_rng;
+   if (prng)
+   rng = current_prng;
+   else
+   rng = current_rng;
+
if (rng)

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

>> The hwrng interface was always meant to be an interface for real
>> hardware random number generators.  People rely on that so we
>> should not provide bogus entropy sources through this interface.
>>
>
> Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
> Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ?
> With that it will be much easier to convert in-tree PRNG that you want to 
> remove.

I do have driver for a PRNG that I was planning to post in sometime.
Upon seeing this thread I think the code has to be changed.

I completely agree with Corentin, adding /dev/prng or /dev/hw_prng
will make it easier to move existing code. It can be made explicit
that using new device will provide only pseudo random number.

Thanks,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[PrasannaKumar Muralidharan]

>> The hwrng interface was always meant to be an interface for real
>> hardware random number generators.  People rely on that so we
>> should not provide bogus entropy sources through this interface.
>>
>
> Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
> Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ?
> With that it will be much easier to convert in-tree PRNG that you want to 
> remove.

I do have driver for a PRNG that I was planning to post in sometime.
Upon seeing this thread I think the code has to be changed.

I completely agree with Corentin, adding /dev/prng or /dev/hw_prng
will make it easier to move existing code. It can be made explicit
that using new device will provide only pseudo random number.

Thanks,
PrasannaKumar

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> > 
> > So I must expose it as a crypto_rng ?
> 
> If it is to be exposed at all then algif_rng would be the best
> place.
> 

I have badly said my question.
So I need to use the HW PRNG in a crypto_rng "provider" that could be 
thereafter used from user space via algif_rng. right ?

> > Could you explain why PRNG must not be used as hw_random ?
> 
> The hwrng interface was always meant to be an interface for real
> hardware random number generators.  People rely on that so we
> should not provide bogus entropy sources through this interface.
> 

Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ?
With that it will be much easier to convert in-tree PRNG that you want to 
remove.

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> > 
> > So I must expose it as a crypto_rng ?
> 
> If it is to be exposed at all then algif_rng would be the best
> place.
> 

I have badly said my question.
So I need to use the HW PRNG in a crypto_rng "provider" that could be 
thereafter used from user space via algif_rng. right ?

> > Could you explain why PRNG must not be used as hw_random ?
> 
> The hwrng interface was always meant to be an interface for real
> hardware random number generators.  People rely on that so we
> should not provide bogus entropy sources through this interface.
> 

Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ?
With that it will be much easier to convert in-tree PRNG that you want to 
remove.

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> 
> So I must expose it as a crypto_rng ?

If it is to be exposed at all then algif_rng would be the best
place.

> Could you explain why PRNG must not be used as hw_random ?

The hwrng interface was always meant to be an interface for real
hardware random number generators.  People rely on that so we
should not provide bogus entropy sources through this interface.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> 
> So I must expose it as a crypto_rng ?

If it is to be exposed at all then algif_rng would be the best
place.

> Could you explain why PRNG must not be used as hw_random ?

The hwrng interface was always meant to be an interface for real
hardware random number generators.  People rely on that so we
should not provide bogus entropy sources through this interface.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Wed, Dec 07, 2016 at 08:09:00PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 01:57:38PM +0100, Corentin Labbe wrote:
> >
> > So how to expose PRNG to user space ? or more generally how to "use" a PRNG 
> > ?
> 
> We do have the algif_rng interface.
> 

So I must expose it as a crypto_rng ?

Could you explain why PRNG must not be used as hw_random ?

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Wed, Dec 07, 2016 at 08:09:00PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 01:57:38PM +0100, Corentin Labbe wrote:
> >
> > So how to expose PRNG to user space ? or more generally how to "use" a PRNG 
> > ?
> 
> We do have the algif_rng interface.
> 

So I must expose it as a crypto_rng ?

Could you explain why PRNG must not be used as hw_random ?

Regards
Corentin Labbe

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Mon, Dec 05, 2016 at 01:57:38PM +0100, Corentin Labbe wrote:
>
> So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?

We do have the algif_rng interface.

> I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as 
> hwrng.

Thanks for checking.  Patches to remove these are welcome.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Mon, Dec 05, 2016 at 01:57:38PM +0100, Corentin Labbe wrote:
>
> So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?

We do have the algif_rng interface.

> I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as 
> hwrng.

Thanks for checking.  Patches to remove these are welcome.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> > From: LABBE Corentin 
> > 
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> Please don't add PRNGs to hwrng.  If we have existing PRNGs in
> there please let me know so that we can remove them.
> 

So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?

I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as 
hwrng.

Regards

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> > From: LABBE Corentin 
> > 
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> Please don't add PRNGs to hwrng.  If we have existing PRNGs in
> there please let me know so that we can remove them.
> 

So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?

I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as 
hwrng.

Regards

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> From: LABBE Corentin 
> 
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
> 
> Signed-off-by: Corentin Labbe 

Please don't add PRNGs to hwrng.  If we have existing PRNGs in
there please let me know so that we can remove them.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Herbert Xu]

On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> From: LABBE Corentin 
> 
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
> 
> Signed-off-by: Corentin Labbe 

Please don't add PRNGs to hwrng.  If we have existing PRNGs in
there please let me know so that we can remove them.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

From: LABBE Corentin 

The Security System have a PRNG.
This patch add support for it as an hwrng.

Signed-off-by: Corentin Labbe 
---
Changes since v1:
 - Replaced all spin_lock_bh by simple spin_lock
 - Removed handling of size not modulo 4 which will never happen
 - Added add_random_ready_callback()

 drivers/crypto/Kconfig   |  8 +++
 drivers/crypto/sunxi-ss/Makefile |  1 +
 drivers/crypto/sunxi-ss/sun4i-ss-core.c  | 14 +
 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 99 
 drivers/crypto/sunxi-ss/sun4i-ss.h   |  9 +++
 5 files changed, 131 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ 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_SUN4I_SS_PRNG
+   bool "Support for Allwinner Security System PRNG"
+   depends on CRYPTO_DEV_SUN4I_SS
+   select HW_RANDOM
+   help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
 config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
 sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   /* Voluntarily made the PRNG optional */
+   err = sun4i_ss_hwrng_register(>hwrng);
+   if (!err)
+   dev_info(ss->dev, "sun4i-ss PRNG loaded");
+   else
+   dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
 error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
 
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   sun4i_ss_hwrng_remove(>hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 000..8319cae
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,99 @@
+#include "sun4i-ss.h"
+
+static void sun4i_ss_seed(struct random_ready_callback *rdy)
+{
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(rdy, struct sun4i_ss_ctx, random_ready);
+   get_random_bytes(ss->seed, SS_SEED_LEN);
+   ss->random_ready.func = NULL;
+}
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+   struct sun4i_ss_ctx *ss;
+   int ret;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+
+   ss->random_ready.owner = THIS_MODULE;
+   ss->random_ready.func = sun4i_ss_seed;
+
+   ret = add_random_ready_callback(>random_ready);
+   switch (ret) {
+   case 0:
+   break;
+   case -EALREADY:
+   get_random_bytes(ss->seed, SS_SEED_LEN);
+   ss->random_ready.func = NULL;
+   ret = 0;
+   break;
+   default:
+   ss->random_ready.func = NULL;
+   }
+
+   return ret;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+  size_t max, bool wait)
+{
+   int i;
+   u32 v;
+   u32 *data = buf;
+   const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+   size_t len;
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+   len = min_t(size_t, SS_DATA_LEN, max);
+
+   /* If the PRNG is not seeded */
+   if (ss->random_ready.func)
+   return -EAGAIN;
+
+   spin_lock(>slock);
+
+   writel(mode, ss->base + SS_CTL);
+
+   /* write the seed */
+   for (i = 0; i < SS_SEED_LEN / 4; i++)
+   writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+   writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+   /* Read the random data */
+   readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+ 

[PATCH v2] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

From: LABBE Corentin 

The Security System have a PRNG.
This patch add support for it as an hwrng.

Signed-off-by: Corentin Labbe 
---
Changes since v1:
 - Replaced all spin_lock_bh by simple spin_lock
 - Removed handling of size not modulo 4 which will never happen
 - Added add_random_ready_callback()

 drivers/crypto/Kconfig   |  8 +++
 drivers/crypto/sunxi-ss/Makefile |  1 +
 drivers/crypto/sunxi-ss/sun4i-ss-core.c  | 14 +
 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 99 
 drivers/crypto/sunxi-ss/sun4i-ss.h   |  9 +++
 5 files changed, 131 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ 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_SUN4I_SS_PRNG
+   bool "Support for Allwinner Security System PRNG"
+   depends on CRYPTO_DEV_SUN4I_SS
+   select HW_RANDOM
+   help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
 config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
 sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   /* Voluntarily made the PRNG optional */
+   err = sun4i_ss_hwrng_register(>hwrng);
+   if (!err)
+   dev_info(ss->dev, "sun4i-ss PRNG loaded");
+   else
+   dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
 error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
 
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   sun4i_ss_hwrng_remove(>hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 000..8319cae
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,99 @@
+#include "sun4i-ss.h"
+
+static void sun4i_ss_seed(struct random_ready_callback *rdy)
+{
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(rdy, struct sun4i_ss_ctx, random_ready);
+   get_random_bytes(ss->seed, SS_SEED_LEN);
+   ss->random_ready.func = NULL;
+}
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+   struct sun4i_ss_ctx *ss;
+   int ret;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+
+   ss->random_ready.owner = THIS_MODULE;
+   ss->random_ready.func = sun4i_ss_seed;
+
+   ret = add_random_ready_callback(>random_ready);
+   switch (ret) {
+   case 0:
+   break;
+   case -EALREADY:
+   get_random_bytes(ss->seed, SS_SEED_LEN);
+   ss->random_ready.func = NULL;
+   ret = 0;
+   break;
+   default:
+   ss->random_ready.func = NULL;
+   }
+
+   return ret;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+  size_t max, bool wait)
+{
+   int i;
+   u32 v;
+   u32 *data = buf;
+   const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+   size_t len;
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+   len = min_t(size_t, SS_DATA_LEN, max);
+
+   /* If the PRNG is not seeded */
+   if (ss->random_ready.func)
+   return -EAGAIN;
+
+   spin_lock(>slock);
+
+   writel(mode, ss->base + SS_CTL);
+
+   /* write the seed */
+   for (i = 0; i < SS_SEED_LEN / 4; i++)
+   writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+   writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+   /* Read the random data */
+   readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+   /* Update the seed */
+   for (i = 0; i <