[PATCH v2 0/1] wcn36xx: Use SNR as a source of system entropy

[PATCH v2 0/1] wcn36xx: Use SNR as a source of system entropy

[Bryan O'Donoghue]

v2:
- Pass sizeof(s8) not sizeof(int) as Loic pointed out only eight bits of data
  are relevant in the SNR.

- Reword the commit log. I didn't really like it on a second reading.
  It describes the theory a little better now I think.

Bryan O'Donoghue (1):
  wcn36xx: Add RX frame SNR as a source of system entropy

 drivers/net/wireless/ath/wcn36xx/txrx.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.37.3

[PATCH v2] wcn36xx: Add RX frame SNR as a source of system entropy

[Bryan O'Donoghue]

The signal-to-noise-ratio SNR is returned by the wcn36xx firmware for each
received frame. SNR represents all of the unwanted interference signal
after filtering out the fundamental frequency and harmonics of the
frequency.

Noise can come from various electromagnetic sources, from temperature
affecting the performance hardware components or quantization effects
converting from analog to digital domains.

The SNR value returned by the WiFi firmware then is a good source of
entropy.

Other WiFi drivers offer up the noise component of the FFT as an entropy
source for the random pool e.g.

commit 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool")

I attended Jason's talk on sources of randomness at Plumbers and it
occurred to me that SNR is a reasonable candidate to add.

Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
 drivers/net/wireless/ath/wcn36xx/txrx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/txrx.c b/drivers/net/wireless/ath/wcn36xx/txrx.c
index 8da3955995b6e..b73229776af8b 100644
--- a/drivers/net/wireless/ath/wcn36xx/txrx.c
+++ b/drivers/net/wireless/ath/wcn36xx/txrx.c
@@ -16,6 +16,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include <linux/random.h>
 #include "txrx.h"
 
 static inline int get_rssi0(struct wcn36xx_rx_bd *bd)
@@ -297,6 +298,8 @@ static void wcn36xx_update_survey(struct wcn36xx *wcn, int rssi, int snr,
 	wcn->chan_survey[idx].rssi = rssi;
 	wcn->chan_survey[idx].snr = snr;
 	spin_unlock(&wcn->survey_lock);
+
+	add_device_randomness(&snr, sizeof(s8));
 }
 
 int wcn36xx_rx_skb(struct wcn36xx *wcn, struct sk_buff *skb)
-- 
2.37.3

Re: [PATCH v2] wcn36xx: Add RX frame SNR as a source of system entropy

[Jason A. Donenfeld]

On Wed, Sep 14, 2022 at 10:28:41PM +0100, Bryan O'Donoghue wrote:
> The signal-to-noise-ratio SNR is returned by the wcn36xx firmware for each
> received frame. SNR represents all of the unwanted interference signal
> after filtering out the fundamental frequency and harmonics of the
> frequency.
> 
> Noise can come from various electromagnetic sources, from temperature
> affecting the performance hardware components or quantization effects
> converting from analog to digital domains.
> 
> The SNR value returned by the WiFi firmware then is a good source of
> entropy.
> 
> Other WiFi drivers offer up the noise component of the FFT as an entropy
> source for the random pool e.g.
> 
> commit 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool")
> 
> I attended Jason's talk on sources of randomness at Plumbers and it
> occurred to me that SNR is a reasonable candidate to add.

Neat!

> Cc: Jason A. Donenfeld <Jason@zx2c4.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
>  drivers/net/wireless/ath/wcn36xx/txrx.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/txrx.c b/drivers/net/wireless/ath/wcn36xx/txrx.c
> index 8da3955995b6e..b73229776af8b 100644
> --- a/drivers/net/wireless/ath/wcn36xx/txrx.c
> +++ b/drivers/net/wireless/ath/wcn36xx/txrx.c
> @@ -16,6 +16,7 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include <linux/random.h>
>  #include "txrx.h"
>  
>  static inline int get_rssi0(struct wcn36xx_rx_bd *bd)
> @@ -297,6 +298,8 @@ static void wcn36xx_update_survey(struct wcn36xx *wcn, int rssi, int snr,
>  	wcn->chan_survey[idx].rssi = rssi;
>  	wcn->chan_survey[idx].snr = snr;
>  	spin_unlock(&wcn->survey_lock);
> +
> +	add_device_randomness(&snr, sizeof(s8));

Won't this break on big endian? Just have an assignment handle it:

    u8 snr_sample = snr & 0xff;
    add_device_randomness(&snr_sample, sizeof(snr_sample);

That & 0xff is redundant, but it doesn't hurt to be explicit.

Jason

Re: [PATCH v2] wcn36xx: Add RX frame SNR as a source of system entropy

[Bryan O'Donoghue]

On 15/09/2022 00:57, Jason A. Donenfeld wrote:
> Won't this break on big endian? Just have an assignment handle it:
> 

Yes but these SoCs are all LE

>      u8 snr_sample = snr & 0xff;
>      add_device_randomness(&snr_sample, sizeof(snr_sample);
> 
> That & 0xff is redundant, but it doesn't hurt to be explicit.

Sure NP I'll v3 it.

---
bod

Re: [PATCH v2] wcn36xx: Add RX frame SNR as a source of system entropy

[Jason A. Donenfeld]

On Thu, Sep 15, 2022 at 01:14:08AM +0100, Bryan O'Donoghue wrote:
> On 15/09/2022 00:57, Jason A. Donenfeld wrote:
> > Won't this break on big endian? Just have an assignment handle it:
> > 
> 
> Yes but these SoCs are all LE

Oh, okay. I thought for some reason that the WCN36xx was just some wifi
chip on a variety of old 32bit ARM SoCs (including Nexus 4's MSM8225
with the Cortex-A5?), some of which I assumed could be biarch. I'm
probably wrong though.

Jason