Message ID | 20220914212841.1407497-2-bryan.odonoghue@linaro.org (mailing list archive) |
---|---|
State | Awaiting Upstream |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [v2] wcn36xx: Add RX frame SNR as a source of system entropy | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Not a local patch |
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
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
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 --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)
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(+)