diff mbox series

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

Message ID 20220914212841.1407497-2-bryan.odonoghue@linaro.org
State Superseded
Headers show
Series wcn36xx: Use SNR as a source of system entropy | expand

Commit Message

Bryan O'Donoghue Sept. 14, 2022, 9:28 p.m. UTC
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(+)

Comments

Jason A. Donenfeld Sept. 14, 2022, 11:57 p.m. UTC | #1
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
Bryan O'Donoghue Sept. 15, 2022, 12:14 a.m. UTC | #2
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
Jason A. Donenfeld Sept. 15, 2022, 1:22 a.m. UTC | #3
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
diff mbox series

Patch

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)