Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. - ret = write_pool(blocking_pool, buffer, count); + ret = write_pool(pool1, buffer, count1); if (ret) return ret; - ret = write_pool(nonblocking_pool, buffer, count); + ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Hi Clemens, Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. -ret = write_pool(blocking_pool, buffer, count); +ret = write_pool(pool1, buffer, count1); if (ret) return ret; -ret = write_pool(nonblocking_pool, buffer, count); +ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? The concern this patch addresses is the following: Both pools have dissimilar use cases. Typically, the blocking_pool is used for cases where more secure random numbers shall be generated whereas the nonblocking_pool shall be used for any other case. The issue now is that both pools intended for different use cases are always updated with the same data. That means, we effectively have two different RNGs (the blocking and nonblocking pool) which are both (re-)seeded with the same data every time when invoking a write on /dev/?random. There is no way that the (re)seed operation mixes both pools with different values. Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. But as writing to the character files is allowed to every user, this per definition must not matter (e.g. an attacker may simply write zeros or other known data into the character file). And the random.c driver handles that case appropriately by not increasing the entropy estimator when receiving data. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Hence, the patch does not change the entropy estimator operation. Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
Stephan Mueller wrote: Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. - ret = write_pool(blocking_pool, buffer, count); + ret = write_pool(pool1, buffer, count1); if (ret) return ret; - ret = write_pool(nonblocking_pool, buffer, count); + ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? [...] Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. Assume that the userspace of an embedded device wants to do the same kind of initialization that a call to add_device_randomness() does, and that it has some data like char serial_number[256]. The padding wouldn't be done intentionally, it's just a property of the data (and it wouldn't have mattered before this patch). But as writing to the character files is allowed to every user, this per definition must not matter (e.g. an attacker may simply write zeros or other known data into the character file). And the random.c driver handles that case appropriately by not increasing the entropy estimator when receiving data. The problem is not with the entropy estimate. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Before this patch, both pools got mixed with the same values. After this patch, both pools indeed get mixed with different values, but now one pool gets mixed with a known value if one half of the buffer happens to be known. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8 v3] crypto:s5p-sss: Add DT and Exynos support
SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However minor changes to the s5p-sss.c driver are required to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds device tree node to Exynos5250 and Exynos5420 4. Adds variant struct to handle the differences in SSS modules 5. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. Naveen Krishna Ch (6): [crypto-2.6.git] crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare Naveen Krishna Chatradhi (2): [linuxsamsung.git] clk:exynos5250: Add gate clock for SSS module ARM: dts: exynos5250/5420: add dt node for sss module .../devicetree/bindings/crypto/samsung-sss.txt | 40 ++ arch/arm/boot/dts/exynos5250.dtsi |8 ++ arch/arm/boot/dts/exynos5420.dtsi | 10 ++ drivers/clk/samsung/clk-exynos5250.c |3 +- drivers/crypto/Kconfig |8 +- drivers/crypto/s5p-sss.c | 131 +++- 6 files changed, 165 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8 v3] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource 0 and hash interrupt as 1.
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v2:
None
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..93cddeb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata-ioaddr = devm_ioremap(dev, res-start,
resource_size(res));
- pdata-irq_hash = platform_get_irq_byname(pdev, hash);
- if (pdata-irq_hash 0) {
- err = pdata-irq_hash;
- dev_warn(dev, hash interrupt is not available.\n);
+ pdata-irq_fc = platform_get_irq(pdev, 0);
+ if (pdata-irq_fc 0) {
+ err = pdata-irq_fc;
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, hash interrupt is not available.\n);
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- pdata-irq_fc = platform_get_irq_byname(pdev, feed control);
- if (pdata-irq_fc 0) {
- err = pdata-irq_fc;
- dev_warn(dev, feed control interrupt is not available.\n);
+ pdata-irq_hash = platform_get_irq(pdev, 1);
+ if (pdata-irq_hash 0) {
+ err = pdata-irq_hash;
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, feed control interrupt is not available.\n);
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8 v3] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v2:
1. Moved the variant struct part to the Exynos support patch
2. Changed the compatible strings to s5pv210-secss
.../devicetree/bindings/crypto/samsung-sss.txt | 20
drivers/crypto/s5p-sss.c | 10 +-
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..2f9d7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - samsung,s5pv210-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts feed control and hash in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..2da5617 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = samsung,s5pv210-secss, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -676,7 +683,8 @@ static struct platform_driver s5p_aes_crypto = {
.remove = s5p_aes_remove,
.driver = {
.owner = THIS_MODULE,
- .name = s5p-secss,
+ .name = s5pv210-secss,
+ .of_match_table = s5p_sss_dt_match,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8 v3] crypto:s5p-sss: Add support for SSS module on Exynos
This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v2:
1. Added variant struct to handle the differences in SSS modules
2. Changed the compatible strings to exynos4210-secss
3. Other changes suggested by Tomasz
.../devicetree/bindings/crypto/samsung-sss.txt | 20
drivers/crypto/s5p-sss.c | 110 +++-
2 files changed, 106 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
index 2f9d7e4..fdc7d8b 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -8,13 +8,33 @@ The SSS module in S5PV210 SoC supports the following:
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
Required properties:
- compatible : Should contain entries for this and backward compatible
SSS versions:
- samsung,s5pv210-secss for S5PV210 SoC.
+ - samsung,exynos4210-secss for Exynos4210, Exynos5250 and Exynos5420 SoCs.
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the SSS module.
Two interrupts feed control and hash in case of S5PV210
+ One interrupts feed control in case of Exynos4210,
+ Exynos5250 and Exynos5420 SoCs.
- clocks : the required gating clock for the SSS module.
- clock-names : the gating clock name to be requested in the SSS driver.
+
+Example:
+ /* SSS_VER_5 */
+ sss@1083 {
+ compatible = samsung,exynos4210-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 471;
+ clock-names = secss;
+ };
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 2da5617..f274f5f 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
#define SSS_REG_FCPKDMAO0x005C
/* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL0x00
#define SSS_AES_BYTESWAP_DI _BIT(11)
#define SSS_AES_BYTESWAP_DO _BIT(10)
#define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,26 @@
#define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
#define SSS_AES_MODE_DECRYPT_BIT(0)
-#define SSS_REG_AES_STATUS 0x4004
+#define SSS_REG_AES_STATUS 0x04
#define SSS_AES_BUSY_BIT(2)
#define SSS_AES_INPUT_READY _BIT(1)
#define SSS_AES_OUTPUT_READY_BIT(0)
-#define SSS_REG_AES_IN_DATA(s) (0x4010 + (s 2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s 2))
-#define SSS_REG_AES_IV_DATA(s) (0x4030 + (s 2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s 2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s 2))
+#define SSS_REG_AES_IN_DATA(off, s)((off + 0x10) + (s 2))
+#define SSS_REG_AES_OUT_DATA(off, s) ((off + 0x20) + (s 2))
+#define SSS_REG_AES_IV_DATA(off, s)((off + 0x30) + (s 2))
+#define SSS_REG_AES_CNT_DATA(off, s) ((off + 0x40) + (s 2))
+#define SSS_REG_AES_KEY_DATA(off, s) ((off + 0x80) + (s 2))
#define SSS_REG(dev, reg) ((dev)-ioaddr + (SSS_REG_##reg))
#define SSS_READ(dev, reg) __raw_readl(SSS_REG(dev, reg))
#define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
+#define SSS_AES_REG(dev, reg) ((dev)-ioaddr + SSS_REG_##reg + \
+ dev-variant-aes_offset)
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val), \
+ SSS_AES_REG(dev, reg))
+
/* HW engine modes */
#define FLAGS_AES_DECRYPT _BIT(0)
#define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -146,6 +151,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_variant - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform
[PATCH 5/8 v3] clk:exynos-5250: Add gate clock for SSS module
This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v2:
This is a new change to support SSS on Exynos5250
drivers/clk/samsung/clk-exynos5250.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index adf3234..b47bf0a 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -120,7 +120,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
- wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
+ wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d, sss,
/* mux clocks */
mout_hdmi = 1024,
@@ -492,6 +492,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
GATE(mixer, mixer, mout_aclk200_disp1, GATE_IP_DISP1, 5, 0, 0),
GATE(hdmi, hdmi, mout_aclk200_disp1, GATE_IP_DISP1, 6, 0, 0),
GATE(g2d, g2d, aclk200, GATE_IP_ACP, 3, 0, 0),
+ GATE(sss, sss, aclk200, GATE_IP_ACP, 2, 0, 0),
};
static struct samsung_pll_rate_table vpll_24mhz_tbl[] __initdata = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8 v3] ARM: dts: exynos5250/5420: add dt node for sss module
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
TO: linux-samsung-...@vger.kernel.org
CC: Kukjin Kim kgene@samsung.com
CC: linux-crypto@vger.kernel.org
---
Changes since v2:
1. Added device tree node for SSS on Exynos5250 aswell
arch/arm/boot/dts/exynos5250.dtsi |8
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index c341e55..1d249df 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -704,4 +704,12 @@
io-channel-ranges;
status = disabled;
};
+
+ sss@1083 {
+ compatible = samsung,exynos4210-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 346;
+ clock-names = secss;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..56a3f3e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = clock 319, clock 318;
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+
+ sss@1083 {
+ compatible = samsung,exynos4210-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 471;
+ clock-names = secss;
+ samsung,power-domain = g2d_pd;
+ };
+
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8 v3] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate iv buffer before trying to memcpy the contents Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- Changes since v2: None drivers/crypto/s5p-sss.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index f274f5f..7058bb6 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -381,8 +381,9 @@ static void s5p_set_aes(struct s5p_aes_dev *dev, struct samsung_aes_variant *var = dev-variant; void __iomem *keystart; - memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA - (var-aes_offset, 0), iv, 0x10); + if (iv) + memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA + (var-aes_offset, 0), iv, 0x10); if (keylen == AES_KEYSIZE_256) keystart = dev-ioaddr + -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8 v3] crypto:s5p-sss: Use clk_prepare/clk_unprepare
This patch set adds use of clk_prepare/clk_unprepare as required by generic clock framework. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- Changes since v2: New change to fix a WARN_ON during the bootup drivers/crypto/s5p-sss.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 7058bb6..3db7e52 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -653,7 +653,7 @@ static int s5p_aes_probe(struct platform_device *pdev) return -ENOENT; } - clk_enable(pdata-clk); + clk_prepare_enable(pdata-clk); spin_lock_init(pdata-lock); pdata-ioaddr = devm_ioremap(dev, res-start, @@ -714,7 +714,7 @@ static int s5p_aes_probe(struct platform_device *pdev) tasklet_kill(pdata-tasklet); err_irq: - clk_disable(pdata-clk); + clk_disable_unprepare(pdata-clk); s5p_dev = NULL; @@ -734,7 +734,7 @@ static int s5p_aes_remove(struct platform_device *pdev) tasklet_kill(pdata-tasklet); - clk_disable(pdata-clk); + clk_disable_unprepare(pdata-clk); s5p_dev = NULL; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
Am Freitag, 10. Januar 2014, 12:37:26 schrieb Clemens Ladisch: Hi Clemens, Stephan Mueller wrote: Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. - ret = write_pool(blocking_pool, buffer, count); + ret = write_pool(pool1, buffer, count1); if (ret) return ret; - ret = write_pool(nonblocking_pool, buffer, count); + ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? [...] Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. Assume that the userspace of an embedded device wants to do the same kind of initialization that a call to add_device_randomness() does, and that it has some data like char serial_number[256]. The padding wouldn't be done intentionally, it's just a property of the data (and it wouldn't have mattered before this patch). But as writing to the character files is allowed to every user, this per definition must not matter (e.g. an attacker may simply write zeros or other known data into the character file). And the random.c driver handles that case appropriately by not increasing the entropy estimator when receiving data. The problem is not with the entropy estimate. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Before this patch, both pools got mixed with the same values. After this patch, both pools indeed get mixed with different values, but now one pool gets mixed with a known value if one half of the buffer happens to be known. Do you imply in your example above that the serial number is unknown? Anything that unprivileged user space tries to inject into /dev/?random should be considered data with known value. Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
Stephan Mueller wrote: Am Freitag, 10. Januar 2014, 12:37:26 schrieb Clemens Ladisch: Stephan Mueller wrote: Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. - ret = write_pool(blocking_pool, buffer, count); + ret = write_pool(pool1, buffer, count1); if (ret) return ret; - ret = write_pool(nonblocking_pool, buffer, count); + ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? [...] Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. Assume that the userspace of an embedded device wants to do the same kind of initialization that a call to add_device_randomness() does, and that it has some data like char serial_number[256]. The padding wouldn't be done intentionally, it's just a property of the data (and it wouldn't have mattered before this patch). But as writing to the character files is allowed to every user, this per definition must not matter (e.g. an attacker may simply write zeros or other known data into the character file). And the random.c driver handles that case appropriately by not increasing the entropy estimator when receiving data. The problem is not with the entropy estimate. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Before this patch, both pools got mixed with the same values. After this patch, both pools indeed get mixed with different values, but now one pool gets mixed with a known value if one half of the buffer happens to be known. Do you imply in your example above that the serial number is unknown? Anything that unprivileged user space tries to inject into /dev/?random should be considered data with known value. Like the kernel's add_device_randomness() function, this example assumes that there is no persistent storage with a saved seed (or that it isn't yet available), and that mixing a device-specific value at least prevents multiple device instances from generating identical random numbers. This indeed helps only against attackers that do not know that serial number. If the data written by unprivileged users to /dev/?random were considered known to *all* attackers, then it wouldn't make sense to allow such writes at all. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8 v3] clk:exynos-5250: Add gate clock for SSS module
Hi Naveen,
On 10.01.2014 12:43, Naveen Krishna Chatradhi wrote:
This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v2:
This is a new change to support SSS on Exynos5250
drivers/clk/samsung/clk-exynos5250.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index adf3234..b47bf0a 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -120,7 +120,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
- wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
+ wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d, sss,
Please base changes to Samsung clock drivers on Mike Turquette's
clk-next [1] or ideally on my samsung-next branch on samsung-clk-tree [2].
By the way, if you assign an ID to a clock, you need to document this in
respective clock bindings documentation.
[1] - https://git.linaro.org/people/mike.turquette/linux.git
[2] - https://git.kernel.org/cgit/linux/kernel/git/tfiga/samsung-clk.git/
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8 v3] crypto:s5p-sss: Use clk_prepare/clk_unprepare
Hi Naveen, On 10.01.2014 12:45, Naveen Krishna Chatradhi wrote: This patch set adds use of clk_prepare/clk_unprepare as required by generic clock framework. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- Changes since v2: New change to fix a WARN_ON during the bootup drivers/crypto/s5p-sss.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8 v3] crypto:s5p-sss: validate iv before memcpy
Hi Naveen, On 10.01.2014 12:45, Naveen Krishna Chatradhi wrote: This patch adds code to validate iv buffer before trying to memcpy the contents Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- Changes since v2: None drivers/crypto/s5p-sss.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index f274f5f..7058bb6 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -381,8 +381,9 @@ static void s5p_set_aes(struct s5p_aes_dev *dev, struct samsung_aes_variant *var = dev-variant; void __iomem *keystart; - memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA - (var-aes_offset, 0), iv, 0x10); + if (iv) + memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA + (var-aes_offset, 0), iv, 0x10); In what conditions can the iv end up being NULL? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
On Fri, Jan 10, 2014 at 12:37:26PM +0100, Clemens Ladisch wrote: Stephan Mueller wrote: Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Rafael Aquini wrote: This patch introduces changes to the random_write method so it can split the given seed and completely stir the output pools with different halves of it, when seed lenght allows us doing so. - ret = write_pool(blocking_pool, buffer, count); + ret = write_pool(pool1, buffer, count1); if (ret) return ret; - ret = write_pool(nonblocking_pool, buffer, count); + ret = write_pool(pool2, buffer + offset, count2); Doesn't this assume that both halves of the buffer contain some (uncredited) entropy? In other words, wouldn't this result in worse randomness for pool2 if the second half of the buffer contains just zero padding? [...] Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. Assume that the userspace of an embedded device wants to do the same kind of initialization that a call to add_device_randomness() does, and that it has some data like char serial_number[256]. The padding wouldn't be done intentionally, it's just a property of the data (and it wouldn't have mattered before this patch). But as writing to the character files is allowed to every user, this per definition must not matter (e.g. an attacker may simply write zeros or other known data into the character file). And the random.c driver handles that case appropriately by not increasing the entropy estimator when receiving data. The problem is not with the entropy estimate. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Before this patch, both pools got mixed with the same values. After this patch, both pools indeed get mixed with different values, but now one pool gets mixed with a known value if one half of the buffer happens to be known. Yeah, nice catch. I haven't thought about it. Theoretically speaking there's no big difference between using the same seed to mix both output pools and split the seed to use its different halves to mix the pools separately in this case. Supposing an attacker could successfully compromise the blocking pool (/dev/random) by injecting a known pattern seed into /dev/urandom, a split seed would also not be able to do any greater good for us, as the attacker can surely handcraft an input that shows the same pattern on both halves. I'm wondering if doing something like initializing an extra structentropy_store, fill in its pool with 'OUTPUT_POOL_SIZE' get_random_bytes(), stir this extra pool with whatever came in as seed from userland and extract two seeds from this pool to then separately stir the output pools would be something more feasible here, or would it just be considered too much for too little... if the approach above is sth worth to pursue, I'll come up with something next week. Thank you all for the comments till here, and have you all a nice weekend! -- Rafael -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
