* [PATCH] NFC: pn533: constify pn533_phy_ops structures
From: Julia Lawall @ 2016-08-09 16:11 UTC (permalink / raw)
To: Lauro Ramos Venancio
Cc: kernel-janitors, Aloisio Almeida Jr, Samuel Ortiz, linux-wireless,
linux-kernel
The pn533_phy_ops are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/nfc/pn533/i2c.c | 2 +-
drivers/nfc/pn533/pn533.c | 2 +-
drivers/nfc/pn533/pn533.h | 4 ++--
drivers/nfc/pn533/usb.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 1dc8924..8a7c17e 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -176,7 +176,7 @@ static irqreturn_t pn533_i2c_irq_thread_fn(int irq, void *data)
return IRQ_HANDLED;
}
-static struct pn533_phy_ops i2c_phy_ops = {
+static const struct pn533_phy_ops i2c_phy_ops = {
.send_frame = pn533_i2c_send_frame,
.send_ack = pn533_i2c_send_ack,
.abort_cmd = pn533_i2c_abort_cmd,
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index d9c5583..2f817b3 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -2560,7 +2560,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
- struct pn533_phy_ops *phy_ops,
+ const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent)
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index 553c7d1..e26d634 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -179,7 +179,7 @@ struct pn533 {
struct device *dev;
void *phy;
- struct pn533_phy_ops *phy_ops;
+ const struct pn533_phy_ops *phy_ops;
};
typedef int (*pn533_send_async_complete_t) (struct pn533 *dev, void *arg,
@@ -226,7 +226,7 @@ struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
void *phy,
- struct pn533_phy_ops *phy_ops,
+ const struct pn533_phy_ops *phy_ops,
struct pn533_frame_ops *fops,
struct device *dev,
struct device *parent);
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index 33ed78b..bcf3f54 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -434,7 +434,7 @@ static void pn533_send_complete(struct urb *urb)
}
}
-static struct pn533_phy_ops usb_phy_ops = {
+static const struct pn533_phy_ops usb_phy_ops = {
.send_frame = pn533_usb_send_frame,
.send_ack = pn533_usb_send_ack,
.abort_cmd = pn533_usb_abort_cmd,
^ permalink raw reply related
* [PATCH] NFC: nfcmrvl: constify nfcmrvl_if_ops structures
From: Julia Lawall @ 2016-08-09 17:03 UTC (permalink / raw)
To: Lauro Ramos Venancio
Cc: kernel-janitors, Aloisio Almeida Jr, Samuel Ortiz, linux-wireless,
linux-kernel
The nfcmrvl_if_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/nfc/nfcmrvl/i2c.c | 2 +-
drivers/nfc/nfcmrvl/main.c | 2 +-
drivers/nfc/nfcmrvl/nfcmrvl.h | 4 ++--
drivers/nfc/nfcmrvl/spi.c | 2 +-
drivers/nfc/nfcmrvl/uart.c | 2 +-
drivers/nfc/nfcmrvl/usb.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c
index 78b7aa8..91d1e67 100644
--- a/drivers/nfc/nfcmrvl/i2c.c
+++ b/drivers/nfc/nfcmrvl/i2c.c
@@ -162,7 +162,7 @@ static void nfcmrvl_i2c_nci_update_config(struct nfcmrvl_private *priv,
{
}
-static struct nfcmrvl_if_ops i2c_ops = {
+static const struct nfcmrvl_if_ops i2c_ops = {
.nci_open = nfcmrvl_i2c_nci_open,
.nci_close = nfcmrvl_i2c_nci_close,
.nci_send = nfcmrvl_i2c_nci_send,
diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
index 51c8240..8e3f26a 100644
--- a/drivers/nfc/nfcmrvl/main.c
+++ b/drivers/nfc/nfcmrvl/main.c
@@ -102,7 +102,7 @@ static struct nci_ops nfcmrvl_nci_ops = {
struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum nfcmrvl_phy phy,
void *drv_data,
- struct nfcmrvl_if_ops *ops,
+ const struct nfcmrvl_if_ops *ops,
struct device *dev,
struct nfcmrvl_platform_data *pdata)
{
diff --git a/drivers/nfc/nfcmrvl/nfcmrvl.h b/drivers/nfc/nfcmrvl/nfcmrvl.h
index de68ff4..d9c2af3 100644
--- a/drivers/nfc/nfcmrvl/nfcmrvl.h
+++ b/drivers/nfc/nfcmrvl/nfcmrvl.h
@@ -88,7 +88,7 @@ struct nfcmrvl_private {
/* PHY type */
enum nfcmrvl_phy phy;
/* Low level driver ops */
- struct nfcmrvl_if_ops *if_ops;
+ const struct nfcmrvl_if_ops *if_ops;
};
struct nfcmrvl_if_ops {
@@ -103,7 +103,7 @@ void nfcmrvl_nci_unregister_dev(struct nfcmrvl_private *priv);
int nfcmrvl_nci_recv_frame(struct nfcmrvl_private *priv, struct sk_buff *skb);
struct nfcmrvl_private *nfcmrvl_nci_register_dev(enum nfcmrvl_phy phy,
void *drv_data,
- struct nfcmrvl_if_ops *ops,
+ const struct nfcmrvl_if_ops *ops,
struct device *dev,
struct nfcmrvl_platform_data *pdata);
diff --git a/drivers/nfc/nfcmrvl/spi.c b/drivers/nfc/nfcmrvl/spi.c
index a7faa0b..f974b45 100644
--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -112,7 +112,7 @@ static void nfcmrvl_spi_nci_update_config(struct nfcmrvl_private *priv,
drv_data->nci_spi->xfer_speed_hz = config->clk;
}
-static struct nfcmrvl_if_ops spi_ops = {
+static const struct nfcmrvl_if_ops spi_ops = {
.nci_open = nfcmrvl_spi_nci_open,
.nci_close = nfcmrvl_spi_nci_close,
.nci_send = nfcmrvl_spi_nci_send,
diff --git a/drivers/nfc/nfcmrvl/uart.c b/drivers/nfc/nfcmrvl/uart.c
index 83a99e3..ad7540e 100644
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -60,7 +60,7 @@ static void nfcmrvl_uart_nci_update_config(struct nfcmrvl_private *priv,
config->flow_control);
}
-static struct nfcmrvl_if_ops uart_ops = {
+static const struct nfcmrvl_if_ops uart_ops = {
.nci_open = nfcmrvl_uart_nci_open,
.nci_close = nfcmrvl_uart_nci_close,
.nci_send = nfcmrvl_uart_nci_send,
diff --git a/drivers/nfc/nfcmrvl/usb.c b/drivers/nfc/nfcmrvl/usb.c
index 585a0f2..ac3796d 100644
--- a/drivers/nfc/nfcmrvl/usb.c
+++ b/drivers/nfc/nfcmrvl/usb.c
@@ -273,7 +273,7 @@ done:
return err;
}
-static struct nfcmrvl_if_ops usb_ops = {
+static const struct nfcmrvl_if_ops usb_ops = {
.nci_open = nfcmrvl_usb_nci_open,
.nci_close = nfcmrvl_usb_nci_close,
.nci_send = nfcmrvl_usb_nci_send,
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:48 UTC (permalink / raw)
To: miaoqing
Cc: kvalo, linux-wireless, ath9k-devel, linux-crypto, smueller,
pouyans
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoqing@codeaurora.org wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Until we get the hw_random/get_device_randomness question sorted...
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:51 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Stephan Mueller, Herbert Xu, Pan, Miaoqing, Matt Mackall,
miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, Sepehrdad, Pouyan
In-Reply-To: <20160809102458.GA20214@khazad-dum.debian.net>
Hi Henrique,
On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Aug 2016, Stephan Mueller wrote:
> > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then
> > broken (at least in those large distros)?
>
> Might I humbly suggest that the kernel start providing some metatada
> about the quality of the random source that userspace can consume?
> Preferably by a new ioctl, so that it will fit naturally if we ever
> extend /dev/hwrng to support more than one source?
>
> That would allow for auto tunning to be implemented in userspace...
See my reply to Keith Packard's proposed multi-device hw_random patch:
https://lkml.kernel.org/r/20160809165710.GC2013@io.lakedaemon.net
and top of thread:
https://lkml.kernel.org/r/1469477255-26824-1-git-send-email-keithp@keithp.com
thx,
Jason.
^ permalink raw reply
* Re: mwifiex: PCIe8997 chip specific handling
From: Brian Norris @ 2016-08-09 18:44 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, linux-kernel
In-Reply-To: <1469788731-5361-1-git-send-email-akarwar@marvell.com>
Hi,
On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> The patch corrects the revision id register and uses it along with
> magic value and chip version registers to download appropriate firmware
> image.
>
> PCIe8997 Z chipset variant code has been removed, as it won't be used in
> production.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 35 ++++++++++-------------------
> drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +++++-------
> 2 files changed, 18 insertions(+), 31 deletions(-)
[...]
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h b/drivers/net/wireless/marvell/mwifiex/pcie.h
> index f6992f0..46f99ca 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> @@ -32,12 +32,9 @@
> #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
Why do version bumps require firmware renames? Is this just to make sure
you don't load the new firmware on old chip revs that you don't plan to
support for production (i.e., only early revs like the _Z you're
dropping)? This doesn't seems like a good long-term solution, at least
once you start getting this silicon out in the wild. At some point, I'd
expect to see a stable file name.
Brian
>
> #define PCIE_VENDOR_ID_MARVELL (0x11ab)
> #define PCIE_VENDOR_ID_V2_MARVELL (0x1b4b)
> @@ -47,9 +44,10 @@
>
> #define PCIE8897_A0 0x1100
> #define PCIE8897_B0 0x1200
> -#define PCIE8997_Z 0x0
> -#define PCIE8997_V2 0x471
> +#define PCIE8997_A0 0x10
> +#define PCIE8997_A1 0x11
> #define CHIP_VER_PCIEUART 0x3
> +#define CHIP_MAGIC_VALUE 0x24
>
> /* Constants for Buffer Descriptor (BD) rings */
> #define MWIFIEX_MAX_TXRX_BD 0x20
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
From: Christian Engelmayer @ 2016-08-09 19:19 UTC (permalink / raw)
To: Larry.Finger, chaoming_li
Cc: kvalo, arnd, linux-wireless, Christian Engelmayer
In case rtl_get_hwinfo() fails, the function directly returns and leaks the
already allocated hwinfo memory. Go through the correct exit path.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
index b0f632462335..57205514801c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
@@ -1757,7 +1757,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
return;
if (rtl_get_hwinfo(hw, rtlpriv, HWSET_MAX_SIZE, hwinfo, params))
- return;
+ goto exit;
_rtl92de_efuse_update_chip_version(hw);
_rtl92de_read_macphymode_and_bandtype(hw, hwinfo);
@@ -1790,6 +1790,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
break;
}
rtlefuse->txpwr_fromeprom = true;
+exit:
kfree(hwinfo);
}
--
2.7.4
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()
From: Christian Engelmayer @ 2016-08-09 19:54 UTC (permalink / raw)
To: Larry.Finger, chaoming_li
Cc: kvalo, arnd, joe, linux-wireless, Christian Engelmayer
In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
returns and leaks the already allocated hwinfo memory. Go through the
correct exit path.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index b88c7ee72dbf..ba30efc2d195 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -1654,7 +1654,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
rtlefuse->autoload_failflag, hwinfo);
if (rtlhal->oem_id != RT_CID_DEFAULT)
- return;
+ goto exit;
switch (rtlefuse->eeprom_oemid) {
case EEPROM_CID_DEFAULT:
--
2.7.4
^ permalink raw reply related
* Re: Google Summer of Code 2016 - Who wants to attend the Mentor Summit
From: chris holcombe @ 2016-08-09 21:03 UTC (permalink / raw)
To: Till Kamppeter, Alexey Khoroshilov, Luis R. Rodriguez, Greg KH,
lsb-discuss@lists.linux-foundation.org, linux-wireless,
Open Printing, Chris MacNaughton, Jan-Simon Möller
In-Reply-To: <9556e237-4936-98d3-ec27-9976577ed55e@gmail.com>
Hey Till,
I'm likely available and it's a short 2hr flight for me. I'd like attend :)
-Chris
On 08/09/2016 01:55 PM, Till Kamppeter wrote:
> Hi,
>
> as every year there is a Mentor Summit at Google in Mountain View,
> California. Two of the mentors or org admins of each organization can
> participate and Google pays the hotel plus 2200 USD (in total for the
> two) to cover travel expenses.
>
> So please tell if you want to attand. Thanks.
>
> Till
>
^ permalink raw reply
* Google Summer of Code 2016 - Who wants to attend the Mentor Summit
From: Till Kamppeter @ 2016-08-09 20:55 UTC (permalink / raw)
To: Alexey Khoroshilov, Luis R. Rodriguez, Greg KH,
lsb-discuss@lists.linux-foundation.org, linux-wireless,
Open Printing, chris holcombe, Chris MacNaughton,
Jan-Simon Möller
Hi,
as every year there is a Mentor Summit at Google in Mountain View,
California. Two of the mentors or org admins of each organization can
participate and Google pays the hotel plus 2200 USD (in total for the
two) to cover travel expenses.
So please tell if you want to attand. Thanks.
Till
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 2:35 UTC (permalink / raw)
To: Stephan Mueller, Herbert Xu
Cc: Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1645997.7cVzaEi3NG@tauon.atsec.com>
Hi Stephan,
For those less perfect noise source, can't pass the FIPS test.
static int update_kernel_random(int random_step,
unsigned char *buf, fips_ctx_t *fipsctx_in)
{
unsigned char *p;
int fips;
fips = fips_run_rng_test(fipsctx_in, buf);
if (fips)
return 1;
for (p = buf; p + random_step <= &buf[FIPS_RNG_BUFFER_SIZE];
p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}
--
Miaoqing
________________________________________
From: Stephan Mueller <smueller@chronox.de>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoqing@codeaurora.org; Valo, Kalle; linux-wireless@vger.kernel.org; ath9k-devel; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.
in rngd_linux.c:random_add_entropy(void *buf, size_t size):
entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);
if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) {
...
in rngd.c:do_loop():
retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
buf, iter->fipsctx);
where update_kernel_random simply invokes random_add_entropy in chunks.
Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.
With less than perfect noise sources, entropy.ent_count should be much
smaller.
>
> Thanks,
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()
From: Larry Finger @ 2016-08-10 14:11 UTC (permalink / raw)
To: Christian Engelmayer, chaoming_li; +Cc: kvalo, arnd, joe, linux-wireless
In-Reply-To: <1470772452-24642-1-git-send-email-cengelma@gmx.at>
On 08/09/2016 02:54 PM, Christian Engelmayer wrote:
> In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
> returns and leaks the already allocated hwinfo memory. Go through the
> correct exit path.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
This patch looks good. Thanks.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> index b88c7ee72dbf..ba30efc2d195 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
> @@ -1654,7 +1654,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
> rtlefuse->autoload_failflag, hwinfo);
>
> if (rtlhal->oem_id != RT_CID_DEFAULT)
> - return;
> + goto exit;
>
> switch (rtlefuse->eeprom_oemid) {
> case EEPROM_CID_DEFAULT:
>
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 7:27 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <c0951e085764481d8d85637734e2e14b@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the
> amount of min entropy the source provides, and not to decide if the source
> has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the entropy we
> expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the
binary decision). Yet, SP800-22 with the associated tool delivers a binary
decision.
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:15 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1526134.1iUazSISyZ@positron.chronox.de>
Hi Stephan,
NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the amount of min entropy the source provides, and not to decide if the source has passed the tests or failed. See
https://github.com/usnistgov/SP800-90B_EntropyAssessment
The goal is often to make sure the input entropy is more than the entropy we expect from the output.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 2:52 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply
* [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
The wrapper rdev_set_coalesce() checks whether the driver provides
the set_coalesce callback and returns -ENOTSUPP if not. However, this
check is already performed in nl80211_set_coalesce() resulting in
-EOPNOTSUPP. This patch removes check from rdev wrapper function.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/rdev-ops.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 85ff30b..903b58a 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1063,11 +1063,10 @@ static inline int
rdev_set_coalesce(struct cfg80211_registered_device *rdev,
struct cfg80211_coalesce *coalesce)
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_set_coalesce(&rdev->wiphy, coalesce);
- if (rdev->ops->set_coalesce)
- ret = rdev->ops->set_coalesce(&rdev->wiphy, coalesce);
+ ret = rdev->ops->set_coalesce(&rdev->wiphy, coalesce);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 4/4] cfg80211: rdev-ops: remove checks from rdev_{add,del}_tx_ts()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrappers check if callback is specified. Just have the checks
in nl80211.c checking the NL80211_FEATURE_SUPPORTS_WMM_ADMISSION
feature flag. If the driver sets this flag the callbacks are being
checked in wiphy_register().
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/core.c | 4 ++++
net/wireless/nl80211.c | 3 +++
net/wireless/rdev-ops.h | 12 +++++-------
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..ef83db8 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -579,6 +579,10 @@ int wiphy_register(struct wiphy *wiphy)
!rdev->ops->tdls_cancel_channel_switch)))
return -EINVAL;
+ if (WARN_ON((wiphy->features & NL80211_FEATURE_SUPPORTS_WMM_ADMISSION)
+ && (!rdev->ops->add_tx_ts || !rdev->ops->del_tx_ts)))
+ return -EINVAL;
+
/*
* if a wiphy has unsupported modes for regulatory channel enforcement,
* opt-out of enforcement checking
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ab63b5..e818cec 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10890,6 +10890,9 @@ static int nl80211_del_tx_ts(struct sk_buff *skb, struct genl_info *info)
u8 tsid;
int err;
+ if (!(rdev->wiphy.features & NL80211_FEATURE_SUPPORTS_WMM_ADMISSION))
+ return -EOPNOTSUPP;
+
if (!info->attrs[NL80211_ATTR_TSID] || !info->attrs[NL80211_ATTR_MAC])
return -EINVAL;
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 2020606..be89461 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -978,13 +978,12 @@ rdev_add_tx_ts(struct cfg80211_registered_device *rdev,
struct net_device *dev, u8 tsid, const u8 *peer,
u8 user_prio, u16 admitted_time)
{
- int ret = -EOPNOTSUPP;
+ int ret;
trace_rdev_add_tx_ts(&rdev->wiphy, dev, tsid, peer,
user_prio, admitted_time);
- if (rdev->ops->add_tx_ts)
- ret = rdev->ops->add_tx_ts(&rdev->wiphy, dev, tsid, peer,
- user_prio, admitted_time);
+ ret = rdev->ops->add_tx_ts(&rdev->wiphy, dev, tsid, peer,
+ user_prio, admitted_time);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
@@ -994,11 +993,10 @@ static inline int
rdev_del_tx_ts(struct cfg80211_registered_device *rdev,
struct net_device *dev, u8 tsid, const u8 *peer)
{
- int ret = -EOPNOTSUPP;
+ int ret;
trace_rdev_del_tx_ts(&rdev->wiphy, dev, tsid, peer);
- if (rdev->ops->del_tx_ts)
- ret = rdev->ops->del_tx_ts(&rdev->wiphy, dev, tsid, peer);
+ ret = rdev->ops->del_tx_ts(&rdev->wiphy, dev, tsid, peer);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 6:25 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <866e31b50f364a87aabe94d2af03ecb8@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not on the
> RNG entropy source. It is not surprising that the RNG input fails the
> entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each
> a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
> where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test, it
> will fail most of the tests, if not all. This does not mean this sequence
> is not appropriate as an entropy source, it just means we need twice more
> bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG
assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If
you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your
noise source to seed a DRNG from (i.e. have an entropy to data ratio of
significantly below 1). And the argument for the oversampling rate is always
a very interesting discussion. You apply 10/32. In private, I am wondering
about that ratio, but this should not be discussed here as I hope you have a
valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise
source before using it. Your current implementation simply does not allow
switching the noise source off to feed the input_pool with data that
increases the entropy estimator (at runtime).
Ciao
Stephan
^ permalink raw reply
* [PATCH 2/4] cfg80211: rdev-ops: remove callback check from rdev_set_mcast_rate()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrapper rdev_set_mcast_rate() checks whether the driver provides
the set_mcast_rate callback and returns -ENOTSUPP if not. However, this
check is already performed in nl80211_set_mcast_rate() resulting in
-EOPNOTSUPP. This patch removes check from rdev wrapper function.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/rdev-ops.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 903b58a..d002415 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1050,11 +1050,10 @@ rdev_set_mcast_rate(struct cfg80211_registered_device *rdev,
struct net_device *dev,
int mcast_rate[NUM_NL80211_BANDS])
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
- if (rdev->ops->set_mcast_rate)
- ret = rdev->ops->set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
+ ret = rdev->ops->set_mcast_rate(&rdev->wiphy, dev, mcast_rate);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] cfg80211: rdev-ops: remove callback check from rdev_start_radar_detection()
From: Arend van Spriel @ 2016-08-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
The wrapper rdev_start_radar_detection() checks whether the driver provides
the start_radar_detection callback and returns -ENOTSUPP if not. However,
this check is already performed in nl80211_start_radar_detection() resulting
in -EOPNOTSUPP. This patch removes check from rdev wrapper function and move
the callback checking in nl80211_start_radar_detection() before the other
checks.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
net/wireless/nl80211.c | 7 ++++---
net/wireless/rdev-ops.h | 7 +++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f02653a..8ab63b5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6826,6 +6826,9 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
unsigned int cac_time_ms;
int err;
+ if (!rdev->ops->start_radar_detection)
+ return -EOPNOTSUPP;
+
dfs_region = reg_get_dfs_region(wdev->wiphy);
if (dfs_region == NL80211_DFS_UNSET)
return -EINVAL;
@@ -6845,15 +6848,13 @@ static int nl80211_start_radar_detection(struct sk_buff *skb,
if (err < 0)
return err;
+ /* 0 value means no dfs is required so bail out */
if (err == 0)
return -EINVAL;
if (!cfg80211_chandef_dfs_usable(wdev->wiphy, &chandef))
return -EINVAL;
- if (!rdev->ops->start_radar_detection)
- return -EOPNOTSUPP;
-
cac_time_ms = cfg80211_chandef_dfs_cac_time(&rdev->wiphy, &chandef);
if (WARN_ON(!cac_time_ms))
cac_time_ms = IEEE80211_DFS_MIN_CAC_TIME_MS;
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index d002415..2020606 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1034,13 +1034,12 @@ rdev_start_radar_detection(struct cfg80211_registered_device *rdev,
struct cfg80211_chan_def *chandef,
u32 cac_time_ms)
{
- int ret = -ENOTSUPP;
+ int ret;
trace_rdev_start_radar_detection(&rdev->wiphy, dev, chandef,
cac_time_ms);
- if (rdev->ops->start_radar_detection)
- ret = rdev->ops->start_radar_detection(&rdev->wiphy, dev,
- chandef, cac_time_ms);
+ ret = rdev->ops->start_radar_detection(&rdev->wiphy, dev,
+ chandef, cac_time_ms);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
--
1.9.1
^ permalink raw reply related
* RE: mwifiex: PCIe8997 chip specific handling
From: Amitkumar Karwar @ 2016-08-10 7:07 UTC (permalink / raw)
To: Brian Norris
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
linux-kernel@vger.kernel.org, Wei-Ning Huang
In-Reply-To: <20160809184406.GA12186@localhost>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Wednesday, August 10, 2016 12:14 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> linux-kernel@vger.kernel.org
> Subject: Re: mwifiex: PCIe8997 chip specific handling
>
> Hi,
>
> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> > The patch corrects the revision id register and uses it along with
> > magic value and chip version registers to download appropriate
> > firmware image.
> >
> > PCIe8997 Z chipset variant code has been removed, as it won't be used
> > in production.
> >
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> > ++++++++++-------------------
> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +++++-------
> > 2 files changed, 18 insertions(+), 31 deletions(-)
>
> [...]
>
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > index f6992f0..46f99ca 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > @@ -32,12 +32,9 @@
> > #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> > #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
>
> Why do version bumps require firmware renames? Is this just to make sure
> you don't load the new firmware on old chip revs that you don't plan to
> support for production (i.e., only early revs like the _Z you're
> dropping)? This doesn't seems like a good long-term solution, at least
> once you start getting this silicon out in the wild. At some point, I'd
> expect to see a stable file name.
>
> Brian
>
We haven't yet submitted any firmware image upstream for 8997 chipset.
pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our firmware candidate for upstream submission. The filename would remain same hereafter.
pcie*8997_combo_v2.bin had support only for A0 chipset
pcie*8997_combo_v3.bin was our internal development version which had support for A1 chipset
pcie*8997_combo_v4.bin has support for both A0 and A1 chipsets and this is the version that shall be released to customers/upstream from now on.
Regards,
Amitkumar Karwar
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
From: Larry Finger @ 2016-08-10 14:10 UTC (permalink / raw)
To: Christian Engelmayer, chaoming_li; +Cc: kvalo, arnd, linux-wireless
In-Reply-To: <1470770397-24390-1-git-send-email-cengelma@gmx.at>
On 08/09/2016 02:19 PM, Christian Engelmayer wrote:
> In case rtl_get_hwinfo() fails, the function directly returns and leaks the
> already allocated hwinfo memory. Go through the correct exit path.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
This patch looks good. Thanks.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
> index b0f632462335..57205514801c 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
> @@ -1757,7 +1757,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
> return;
>
> if (rtl_get_hwinfo(hw, rtlpriv, HWSET_MAX_SIZE, hwinfo, params))
> - return;
> + goto exit;
>
> _rtl92de_efuse_update_chip_version(hw);
> _rtl92de_read_macphymode_and_bandtype(hw, hwinfo);
> @@ -1790,6 +1790,7 @@ static void _rtl92de_read_adapter_info(struct ieee80211_hw *hw)
> break;
> }
> rtlefuse->txpwr_fromeprom = true;
> +exit:
> kfree(hwinfo);
> }
>
>
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:40 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4321952.1nMxxDi7Wz@positron.chronox.de>
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 5:29 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1470796501856.53342@qti.qualcomm.com>
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> For those less perfect noise source, can't pass the FIPS test.
>
> static int update_kernel_random(int random_step,
> unsigned char *buf, fips_ctx_t *fipsctx_in)
> {
> unsigned char *p;
> int fips;
>
> fips = fips_run_rng_test(fipsctx_in, buf);
> if (fips)
> return 1;
>
> for (p = buf; p + random_step <= &buf[FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use
add_device_randomness.
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:43 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1e8e88ad7de64c528f08c75ff9176ab8@aptaiexm02f.ap.qualcomm.com>
Hi Stephan,
The problem with using the add_device_randomness is that we do not know when to call that API, and we have to make our solution either timer-based or interrupt based, which is not really the correct way of implementing this feature.
Thanks,
Miaoqing
-----Original Message-----
From: Pan, Miaoqing
Sent: Wednesday, August 10, 2016 3:41 PM
To: Stephan Mueller <smueller@chronox.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v2 8/8] p54: convert to sysdata API
From: Luis R. Rodriguez @ 2016-08-10 18:32 UTC (permalink / raw)
To: Linus Torvalds, Bjorn Andersson, Daniel Vetter, Kalle Valo,
Ming Lei, Greg Kroah-Hartman, Daniel Wagner, Jeff Mahoney,
Arend van Spriel, Takashi Iwai
Cc: Luis R. Rodriguez, Hauke Mehrtens, Vikram Mulukutla, Stephen Boyd,
Christian Lamparter, Andy Lutomirski, Jonathan Corbet,
Julia Lawall, Tom Gundersen, Kay Sievers, David Woodhouse,
Andrew Morton, Tejun Heo, Josh Boyer, Michal Marek, David Howells,
Mimi Zohar, Johannes Berg, Daniel Vetter, Abhay_Salunke,
Dmitry Torokhov, Wu Fengguang, Mark Brown, Kees Cook, Jiri Slaby,
Gilles.Muller, Linux Kernel Mailing List, linux-wireless,
Borislav Petkov, Richard Purdie, nicolas.palix
In-Reply-To: <20160617183503.GV11948@wotan.suse.de>
On Fri, Jun 17, 2016 at 08:35:03PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jun 16, 2016 at 05:09:30PM -1000, Linus Torvalds wrote:
> > On Thu, Jun 16, 2016 at 3:36 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> > >
> > > Reason this could not wait is folks seem to want to keep extending the API,
> > > which is another reason for this, do we want to put an end to an unflexible
> > > API now or should we wait ?
> >
> > So I absolutely abhor "changes for changes sake".
> >
> > If the existing code works for existing drivers, let them keep it.
> >
> > And if a new interface is truly more flexible, then it should be able
> > to implement the old interface with no changes, so that drivers
> > shouldn't need to be changed/upgraded.
>
> Are we OK to leave only the usermode helper support in place for the
> 2 drivers I've noted that explicitly require the usermode helper in their
> firmware request [0] ?
>
> If so then I can do what you recommend below.
>
> > Then, drivers that actually _want_ new features, or that can take
> > advantage of new interfaces to actually make things *simpler*, can
> > choose to make those changes. But those changes should have real
> > advantages.
As I noted above -- this still needs to be decided.
We only have 2 more drivers using the usermode helper explicitly now. Other
than this we have the old CONFIG_FW_LOADER_USER_HELPER_FALLBACK -- which
explicitly forced the usermode helper on every call. This later option is no
longer widely used by distributions, and distros these days just enable
CONFIG_FW_LOADER_USER_HELPER, with this only 2 drivers are using the usermode
helper. This still should mean we should not break users of
CONFIG_FW_LOADER_USER_HELPER_FALLBACK, as stupid as it may have been.
My preferred approach is as follows (and this is what I'll follow unless
I hear otherwise):
Obviously let's not break CONFIG_FW_LOADER_USER_HELPER_FALLBACK -- even if it
logically means long term most drivers if not all will convert to the new API,
there is no need for a full swing change. Lets leave drivers as-is, given most
distros are sensible and only enabling CONFIG_FW_LOADER_USER_HELPER. Given
most distros disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK, and we have now
verified only 2 explicit user mode helper scallers exists this means we have
mostly put away most of the sore of the user mode helper. With Daniel Wagner's
change to change the firmware API to use the new swait stuff it further pushes
some other user mode helper crap away [0]. Then, only drivers *that care and
want to change* to the new API will do so but we put a stop gap measure so that
new features only go through the new API. This means we mark
CONFIG_FW_LOADER_USER_HELPER_FALLBACK as deprecated.
We can strive to mark CONFIG_FW_LOADER_USER_HELPER as deprecated but to be fair
this requires more work:
Despite my best efforts to call out for valid new uses of the user mode helper
the only valid use I've heard so far over CONFIG_FW_LOADER_USER_HELPER was for
huge files for remoteproc as explained by Bjorn Andersson given the
deterministic aspect issue of ensuring a file is ready and also that they
cannot use initramfs to stuff the firmware [1]. As recently discussed in that
same thread with Bjorn though we can easily just add this upstream either as
a simple file sentinel or better yet -- a simple event from userspace [2] to
be used either to indicate the rootfs is ready or if we wanted farther
granularity per enum kernel_read_file_id (READING_FIRMWARE, READING_MODULE,
READING_KEXEC_IMAGE, READING_KEXEC_INITRAMFS, READING_POLICY), and that would
seem to put everyone's concerns over direct file loading at ease, including
Bjorn's [1]. This needs to be implemented. When that is done -- unless we hear
otherwise over requirements for the usermode helper -- we can finally mark
CONFIG_FW_LOADER_USER_HELPER as deprecated.
[0] https://lkml.kernel.org/r/1470313636-670-1-git-send-email-wagi@monom.org
[1] https://lkml.kernel.org/r/20160803173955.GD13516@tuxbot
[2] https://lkml.kernel.org/r/20160803184058.GS3296@wotan.suse.de
> Sure agreed.
>
> > Having to have a callback,
>
> This is because devm is not used, as such the consumer is needed prior to
> freeing. I can give adding devm support a shot if folks seem to be generally
> agree its the right approach. I do expect this will mean tons of code
> deletions and helping with bugs.
Regarding this -- Dmitry recenlty noted devm only works if used on the probe
path, and as we now determined, we don't want firmware loading on probe [3], unless
async probe is used, so this would make a devm solution here not ideal for
freeing the firmware. Even if you use async probe -- that seems very special
use case and adding devm support for the firmware API just for that seems silly.
As such the current devised solution in the sysdata API is called for, given
if you indicated that keep = false, you are explicitly telling the firmware
API that your firmware will certainly not be needed after the callback is
called.
So for the sync case, a new callback is needed, and that explains the extra
bit of code if someone conerts from the old API to the new one.
[3] https://lkml.kernel.org/r/20160803161821.GB32965@dtor-ws
> > or a magical "sysdata_desc" descriptor,
>
> This is one way to make a flexible and extensible API without affecting drivers
> with further collateral evolutions as it gets extended. Its no different than
> the "flags" lesson learned from writing system calls, for instance.
>
> Descriptor seemed, fitting, let me know if you have any other preference.
I haven't heard otherwise so will be sticking to that.
> > and having a new name ("sysdata") that is less descriptive than the old one
> > ("firmware")
>
> Well no, the APIs are used in *a lot* of cases for things that are not firmware
> already, and let's recall I originally started working on this to replace CRDA
> from userspace to be able to just fetch the signed regulatory database file
> from the kernel. Calling it firmware simply makes no sense anymore.
So help me bike shed. This seems to be sticking point and I frankly don't
care what we call it. I've asked others for name suggestions and here are
a few suggestions:
o driver_data
o dsd: device specific data
o xfw - eXtensible firmware API
o bbl - binary blob loader
Can someone just pick something? I really, really do not care.
If I don't hear anything concrete I will go with driver_data.
> > are all in my opinion making the example patch be a
> > step _backwards_ rather than an improvement. It does not look like a
> > simpler or more natural interface for a driver.
>
> Hope the above explains the current state. Feedback on desirable changes
> welcomed.
>
> [0] https://lkml.kernel.org/r/1466117661-22075-5-git-send-email-mcgrof@kernel.org
All this said, this series is still justified, the extra code only comes in
place when porting the sync requests due to the callback stuff described above
and the inability to use devm there. As far as I can tell, just the bike
shedding is left.
As it stands then, unless I hear back, I'll roll Daniel Wagner's changes into
my series to be applied first, then rename sysdata driver_data, rebase all this
and shoot it out again.
Only a few drivers will be converted over as demos. The SmPL grammar can be used
by those who do want a change due to the few features added. Long term we'll
add more features to the new API:
o the whole ihex conversion is crap, we should do this within the API and
this can just be specified as a descriptor preference, then drivers
don't have to deal with the ihex crap themselves.
o firmware singing - this lets us kill CRDA as a requirement
Luis
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 6:51 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <82844e4b56c9475fabf22b3fe12b53bb@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox