Re: [RFC PATCH 2/2] Crypto kernel tls socket

2015-11-23 Thread Sowmini Varadhan 
On (11/23/15 09:43), Dave Watson wrote:
> Currently gcm(aes) represents ~80% of our SSL connections.
> 
> Userspace interface:
> 
> 1) A transform and op socket are created using the userspace crypto interface
> 2) Setsockopt ALG_SET_AUTHSIZE is called
> 3) Setsockopt ALG_SET_KEY is called twice, since we need both send/recv keys
> 4) ALG_SET_IV cmsgs are sent twice, since we need both send/recv IVs.
>To support userspace heartbeats, changeciphersuite, etc, we would also need
>to get these back out, use them, then reset them via CMSG.
> 5) ALG_SET_OP cmsg is overloaded to mean FD to read/write from.

[from patch 0/2:]
> If a non application-data TLS record is seen, it is left on the TCP
> socket and an error is returned on the ALG socket, and the record is
> left for userspace to manage.

Interesting approach.

FWIW, I was hoping to discuss solutions for securing traffic tunnelled
over L3 at netdev 1.1, so hopefully we'll be able to go over the
trade-offs there. 

I'm trying to see how your approach would fit with the RDS-type of
use-case. RDS-TCP is mostly similar in concept to kcm,
except that rds has its own header for multiplexing, and has no 
dependancy on BPF for basic things like re-assembling the datagram. 
If I were to try to use this for RDS-TCP, the tls_tcp_read_sock() logic
would be merged into the recv_actor callback for RDS, right?  Thus tls
control-plane message could be seen in the middle of the
data-stream, so we really have to freeze the processing of the data
stream till the control-plane message is processed?

I'm concerned about the possiblilites for async that can happen when
we separate the data-plane from the control-plane (uspace tls
does not have to deal with this), but we now have control plane
separated from data-plane. (And IPsec/IKE has plenty of headaches
from this sort of thing already)

In the tls.c example that you have, the opfd is generated from
the accept() on the AF_ALG socket- how would this work if I wanted
my opfd to be a PF_RDS or a PF_KCM or similar?

One concern is that this patchset provides a solution for the "80%"
case but what about the other 20% (and the non x86 platforms)?
E.g., if I get a cipher-suite request outside the aes-ni, what would
happen (punt to uspace?)

--Sowmini

--
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: hwrng: Some concerns about add_hwgenerator_randomness

2015-11-23 Thread Stephan Mueller 
Am Sonntag, 22. November 2015, 02:15:12 schrieb Nick Kossifidis:

Hi Nick,

>Hello all,
>
>I've been doing some reading on hw_random core and the drivers that
>use it and it seems that three of them use the quality parameter on
>the hwrng struct. When a driver sets this value, it ends up directly
>on credit_entropy_bits in random through add_hwgenerator_randomness
>and there is no way of disabling this behavior.

IIRC, you can disable or alter the quality value them using the kernel command 
line.
>
>Even if the user sets hw_random's default_quality to 0 (the
>default/safe value), the value on the hwrng struct overrides it:
>
>hw_random/core.c:
>current_quality = rng->quality ? : default_quality;

Looking at that code, I would think that this is wrong as this overwrites the 
kernel command line option.
>
>The three drivers that set rng->quality are:
>
>virtio-rng: sets it to 1000
>chaoskey: sets it to 1024 + 1023 (!) which gets re-set to 1024 in hwrng_init
>zcrypt: sets it to 900 by default but provides a module option to
>disable this behavior and set it to 0 (so that's an exception)
>
>I suggest to use the quality parameter of hwrng as "minimum entropy"
>or "guaranteed entropy" of the hwrng and if default_quality (the value
>set by the user) is larger than this, use it as an upper boundary
>(because the device can't "guarantee" more entropy), else If
>default_quality is less than this or zero, use default_quality
>instead. Do you agree with this, should I send a patch for it ?
>
>Also there is another issue when drivers call
>add_hwgenerator_randomness directly, ath9k does this -on
>wireless-testing- to provide random data from its ADC and use the
>wireless card as an entropy source. Other drivers might also do it in
>the future (I couldn't find more users other than hw_random/core.c and
>ath9k for now). Again there is no way to check or override the quality
>parameter passed there and it goes directly to random's
>credit_entropy_bits. Is this function meant to be used by anyone or is
>it an API between hw_random and random only ? The documentation on
>hw_random (it's declared on hw_random.h) hasn't been updated to
>reflect how this function should be used or what restrictions apply to
>the quality parameter when used (the commit log said that developers
>should be careful but nothing specific).
>
>We could have a parameter like "max_hwgenerator_quality" on random
>that makes it possible to filter the quality parameter passed on
>add_hwgenerator_randomness, no matter who uses it.
>
>Finally I suggest that we have an ioctl on random to completely
>disable add_hwgenerator_randomness and that's because if someone wants

Again, I thought you can set that with the kernel command line, provided the 
aforementioned code is changed.

>to use a userspace daemon to seed random through /dev/hwrng by doing
>further statistical analysis/monitoring (e.g. rngd or something
>similar), he/she will be mixing the same data on the pool twice (one
>through hw_random -> add_hwgenerator_randomness -even with zero
>quality- and one trough sysctl). I 'd also like to send a patch for
>this if you agree.
>
>Thanks a lot for your time, have a nice weekend.


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

[PATCH] crypto: Docs blurb about templates.

2015-11-23 Thread Andrew Zaborowski 
Signed-off-by: Andrew Zaborowski 
---
These are some notes about the template structs that can take some
head-scratching to figure out from the code.  Please check that this is
the current intended use.
---
 Documentation/crypto/api-intro.txt | 40 ++
 1 file changed, 40 insertions(+)

diff --git a/Documentation/crypto/api-intro.txt 
b/Documentation/crypto/api-intro.txt
index 8b49302..39b5caa 100644
--- a/Documentation/crypto/api-intro.txt
+++ b/Documentation/crypto/api-intro.txt
@@ -117,6 +117,46 @@ Also check the TODO list at the web site listed below to 
see what people
 might already be working on.
 
 
+TEMPLATE ALGORITHMS
+
+Templates dynamically create algorithms based on algorithm names passed
+as parameters.  In most cases they modify how another algorithm works by
+wrapping around an instance of the other algorithm and operating on its
+inputs, outputs, and/or the keys.  They can call the child transform's
+operations in an arbitrary order.  The template can convert one algorithm
+type to another and may also combine multiple instances of one or
+multiple algorithms.
+
+The following additional types are used with templates:
+
+* struct crypto_template
+  Describes the template and has methods to create actual algorithms as
+  crypto_instance structures.  These are not instances of algorithms
+  (transforms), instances of the template are algorithms.  The template
+  does not appear in /proc/crypto but the algorithms do.  The struct
+  crypto_template does not statically determine the resulting crypto
+  types.
+
+* struct crypto_instance
+  Represents an instance of a template.  Its first member is the
+  "struct crypto_alg alg" which is a dynamically created algorithm that
+  behaves like any other.  The structure also points back to the template
+  used.  The crypto type-specific methods and other algorithm context is
+  prepended to struct crypto_instance in a way that it's also prepended
+  to the .alg member.  The children algorithm(s) used by the template
+  instance are pointed to by the crypto_spawn structure(s) normally
+  appended after the crypto_instance.
+
+  Actual transforms are created when the context is allocated and .init_tfm
+  is called same as with non-template algorithms, but the .init_tfm
+  function will need to trigger creation of child transform(s) from the
+  crypto_spawn structure(s).
+
+* struct crypto_spawn
+  Links a template algorithm (crypto_instance) and a reference to one child
+  algorithm.
+
+
 BUGS
 
 Send bug reports to:
-- 
2.1.4

--
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] crypto: atmel: fix 64-bit warnings

2015-11-23 Thread Herbert Xu 
On Tue, Nov 17, 2015 at 10:22:06AM +0100, Arnd Bergmann wrote:
> The atmel AES driver assumes that 'int' and 'size_t' are the same
> type in multiple locations, which the compiler warns about when
> building it for 64-bit systems:
> 
> In file included from ../drivers/crypto/atmel-aes.c:17:0:
> drivers/crypto/atmel-aes.c: In function 'atmel_aes_sg_copy':
> include/linux/kernel.h:724:17: warning: comparison of distinct pointer types 
> lacks a cast
> drivers/crypto/atmel-aes.c:448:11: note: in expansion of macro 'min'
> 
> drivers/crypto/atmel-aes.c: In function 'atmel_aes_crypt_dma_stop':
> include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of 
> type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned int}' 
> [-Wformat=]
> 
> This changes the format strings to use the %z modifier when printing
> a size_t, and makes sure that we use the correct size_t type where
> needed. In case of sg_dma_len(), the type of the result depends
> on CONFIG_NEED_SG_DMA_LENGTH, so we have to use min_t to get it to
> work in all configurations.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 2/2] crypto: mcryptd - use list_first_entry_or_null()

2015-11-23 Thread Herbert Xu 
On Mon, Nov 16, 2015 at 10:37:15PM +0800, Geliang Tang wrote:
> Simplify mcryptd_opportunistic_flush() with list_first_entry_or_null().
> 
> Signed-off-by: Geliang Tang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2] hw_random: omap3-rom-rng: convert timer to delayed work

2015-11-23 Thread Herbert Xu 
On Wed, Nov 18, 2015 at 09:59:01PM +0200, Aaro Koskinen wrote:
> We cannot put the HW RNG to idle using a timer because we cannot disable
> clocks from atomic context. Use a delayed work instead.
> 
> Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.
> 
> Reported-by: Sebastian Reichel 
> Signed-off-by: Aaro Koskinen 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v4 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288

2015-11-23 Thread Herbert Xu 
On Tue, Nov 17, 2015 at 12:00:46PM +0800, Zain Wang wrote:
>
> +static void rk_ablk_hw_init(struct rk_crypto_info *dev)
> +{
> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(dev->ablk_req);
> + struct rk_cipher_ctx *ctx = crypto_ablkcipher_ctx(tfm);
> + u32 conf_reg = 0;
> +
> + if (dev->mode & TDES) {
> + dev->mode &= ~TDES;
> + dev->mode |= RK_CRYPTO_TDES_FIFO_MODE |
> +  RK_CRYPTO_TDES_BYTESWAP_KEY |
> +  RK_CRYPTO_TDES_BYTESWAP_IV;
> + CRYPTO_WRITE(dev, RK_CRYPTO_TDES_CTRL, dev->mode);
> +
> + memcpy(dev->reg + RK_CRYPTO_TDES_IV_0, dev->ablk_req->info, 8);

Please ensure that the IV is copied back after the operation.
I know that many existing drivers are buggy in this regard but
they will be fixed soon and we will start enforcing this rule
so I don't want to add any new drivers that break this rule.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 1/2] crypto: api - use list_first_entry_or_null and list_next_entry

2015-11-23 Thread Herbert Xu 
On Mon, Nov 16, 2015 at 10:37:14PM +0800, Geliang Tang wrote:
> Simplify crypto_more_spawns() with list_first_entry_or_null()
> and list_next_entry().
> 
> Signed-off-by: Geliang Tang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 1/1] crypto: tcrypt: fix keysize argument of test_aead_speed for gcm(aes)

2015-11-23 Thread Herbert Xu 
On Tue, Nov 17, 2015 at 01:37:10PM +0100, Cyrille Pitchen wrote:
> The key sizes used by AES in GCM mode should be 128, 192 or 256 bits (16,
> 24 or 32 bytes).
> There is no additional 4byte nonce as for RFC 4106.
> 
> Signed-off-by: Cyrille Pitchen 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v3] crypto: atmel: fix bogus select

2015-11-23 Thread Herbert Xu 
On Wed, Nov 18, 2015 at 04:33:54PM +0100, Arnd Bergmann wrote:
> >From 0d53d42a56e9a3769847fd03c703876f2c063fb4 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann 
> Date: Tue, 27 Jan 2015 22:34:04 +0100
> Subject: [PATCH] [SUBMITTED] crypto: atmel: fix bogus select
> 
> The Atmel at91 crypto driver unconditionally selects AT_HDMAC,
> which results in a Kconfig warning if that driver is not enabled:
> 
> warning: (CRYPTO_DEV_ATMEL_AES) selects AT_HDMAC which has unmet direct 
> dependencies (DMADEVICES && ARCH_AT91)
> 
> The crypto driver itself does not actually have a dependency
> on a particular dma engine, other than this being the one that
> is used in at91.
> 
> Removing the 'select' gets rid of the warning, but can cause
> the driver to be unusable if the HDMAC is not enabled at the
> same time. To work around that, this patch clarifies the runtime
> dependency to be 'AT_HDMAC || AT_XDMAC', but adds an alternative
> for COMPILE_TEST, which lets the driver get build on all systems.
> 
> The ARCH_AT91 dependency is implied by AT_XDMAC || AT_HDMAC now
> and no longer needs to be listed separately.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 1/2] crypto: sahara: set nb_[in|out]_sg as signed int

2015-11-23 Thread Herbert Xu 
On Thu, Nov 19, 2015 at 01:38:17PM +0100, LABBE Corentin wrote:
> The two unsigned int variables nb_in_sg and nb_out_sg can be assigned
> signed value (-EINVAL) from sg_nents_for_len().
> Furthermore they are used only by dma_map_sg and dma_unmap_sg which wait
> for an signed int, so they must be set as int.
> 
> Fixes: 6c2b74d4774f ("crypto: sahara - check return value of 
> sg_nents_for_len")
> Reported-by: Dan Carpenter 
> Signed-off-by: LABBE Corentin 

Both patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] crypto: nx: use of_property_read_u32()

2015-11-23 Thread Saurabh Sengar 
use of_propert_read_u32() for reading int value,
it can help reducing number of variables used

Signed-off-by: Saurabh Sengar 
---
 drivers/crypto/nx/nx-842-powernv.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 9ef51fa..87f7a0f 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -525,7 +525,6 @@ static int nx842_powernv_decompress(const unsigned char 
*in, unsigned int inlen,
 static int __init nx842_powernv_probe(struct device_node *dn)
 {
struct nx842_coproc *coproc;
-   struct property *ct_prop, *ci_prop;
unsigned int ct, ci;
int chip_id;
 
@@ -534,18 +533,16 @@ static int __init nx842_powernv_probe(struct device_node 
*dn)
pr_err("ibm,chip-id missing\n");
return -EINVAL;
}
-   ct_prop = of_find_property(dn, "ibm,842-coprocessor-type", NULL);
-   if (!ct_prop) {
+
+   if (of_property_read_u32(dn, "ibm,842-coprocessor-type", )) {
pr_err("ibm,842-coprocessor-type missing\n");
return -EINVAL;
}
-   ct = be32_to_cpu(*(unsigned int *)ct_prop->value);
-   ci_prop = of_find_property(dn, "ibm,842-coprocessor-instance", NULL);
-   if (!ci_prop) {
+
+   if (of_property_read_u32(dn, "ibm,842-coprocessor-instance", )) {
pr_err("ibm,842-coprocessor-instance missing\n");
return -EINVAL;
}
-   ci = be32_to_cpu(*(unsigned int *)ci_prop->value);
 
coproc = kmalloc(sizeof(*coproc), GFP_KERNEL);
if (!coproc)
-- 
1.9.1

--
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] crypto: nx: use of_property_read_u32()

2015-11-23 Thread Dan Streetman 
On Mon, Nov 23, 2015 at 4:56 AM, Saurabh Sengar  wrote:
> use of_propert_read_u32() for reading int value,
> it can help reducing number of variables used
>
> Signed-off-by: Saurabh Sengar 

Acked-by: Dan Streetman 

> ---
>  drivers/crypto/nx/nx-842-powernv.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
> b/drivers/crypto/nx/nx-842-powernv.c
> index 9ef51fa..87f7a0f 100644
> --- a/drivers/crypto/nx/nx-842-powernv.c
> +++ b/drivers/crypto/nx/nx-842-powernv.c
> @@ -525,7 +525,6 @@ static int nx842_powernv_decompress(const unsigned char 
> *in, unsigned int inlen,
>  static int __init nx842_powernv_probe(struct device_node *dn)
>  {
> struct nx842_coproc *coproc;
> -   struct property *ct_prop, *ci_prop;
> unsigned int ct, ci;
> int chip_id;
>
> @@ -534,18 +533,16 @@ static int __init nx842_powernv_probe(struct 
> device_node *dn)
> pr_err("ibm,chip-id missing\n");
> return -EINVAL;
> }
> -   ct_prop = of_find_property(dn, "ibm,842-coprocessor-type", NULL);
> -   if (!ct_prop) {
> +
> +   if (of_property_read_u32(dn, "ibm,842-coprocessor-type", )) {
> pr_err("ibm,842-coprocessor-type missing\n");
> return -EINVAL;
> }
> -   ct = be32_to_cpu(*(unsigned int *)ct_prop->value);
> -   ci_prop = of_find_property(dn, "ibm,842-coprocessor-instance", NULL);
> -   if (!ci_prop) {
> +
> +   if (of_property_read_u32(dn, "ibm,842-coprocessor-instance", )) {
> pr_err("ibm,842-coprocessor-instance missing\n");
> return -EINVAL;
> }
> -   ci = be32_to_cpu(*(unsigned int *)ci_prop->value);
>
> coproc = kmalloc(sizeof(*coproc), GFP_KERNEL);
> if (!coproc)
> --
> 1.9.1
>
--
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 2/2] Crypto kernel tls socket

2015-11-23 Thread Sowmini Varadhan 
On (11/23/15 13:43), Dave Watson wrote:
> 
> For kcm, opfd is the fd you would pass along in kcm_attach.
> For rds, it looks like you'd want to use opfd as the sock instead of
> the new one created by sock_create_kern in rds_tcp_conn_connect.

I see.

It's something to consider, and it would certainly secure the
RDS header and app data, but TLS by itself may not be
enough- we'd need to protect the TCP control plane as well, and 
at the moment, I'm finding that even using esp-null (or AO, or MD5,
for that matter) means that I lose GSO, and perf tanks. I'll try to
put all my data together for this for netdev 1.1.


> > E.g., if I get a cipher-suite request outside the aes-ni, what would
> > happen (punt to uspace?)
> >
> > --Sowmini
> 
> Right, bind() would fail and you would fallback to uspace.

That's the approach that Solaris KSSL took, back in 1999. It quickly
became obsolete, again more details in netdev 1.1.

--Sowmini
--
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 v4 2/4] clk: rockchip: set an ID for crypto clk

2015-11-23 Thread Heiko Stübner 
Hi Zain,

Am Dienstag, 17. November 2015, 12:00:45 schrieb Zain Wang:
> Set an ID for crypto clk, so that it can be called in other part.
> 
> Signed-off-by: Zain Wang 
> Acked-by: Michael Turquette 
> Tested-by: Heiko Stuebner 

I've split this into the header and clk-rk3288.c changes and applied it to my 
clk-ids and clock branch for 4.5


Thanks
Heiko
--
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 v4 2/4] clk: rockchip: set an ID for crypto clk

2015-11-23 Thread Zain 


On 2015年11月24日 07:24, Heiko Stübner wrote:
> Hi Zain,
>
> Am Dienstag, 17. November 2015, 12:00:45 schrieb Zain Wang:
>> Set an ID for crypto clk, so that it can be called in other part.
>>
>> Signed-off-by: Zain Wang 
>> Acked-by: Michael Turquette 
>> Tested-by: Heiko Stuebner 
> I've split this into the header and clk-rk3288.c changes and applied it to my 
> clk-ids and clock branch for 4.5
Thanks for your responding.

Thanks
Zain
>
> Thanks
> Heiko
>
>
>


--
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 v4 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288

2015-11-23 Thread Zain 


On 2015年11月23日 20:51, Herbert Xu wrote:
> On Tue, Nov 17, 2015 at 12:00:46PM +0800, Zain Wang wrote:
>> +static void rk_ablk_hw_init(struct rk_crypto_info *dev)
>> +{
>> +struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(dev->ablk_req);
>> +struct rk_cipher_ctx *ctx = crypto_ablkcipher_ctx(tfm);
>> +u32 conf_reg = 0;
>> +
>> +if (dev->mode & TDES) {
>> +dev->mode &= ~TDES;
>> +dev->mode |= RK_CRYPTO_TDES_FIFO_MODE |
>> + RK_CRYPTO_TDES_BYTESWAP_KEY |
>> + RK_CRYPTO_TDES_BYTESWAP_IV;
>> +CRYPTO_WRITE(dev, RK_CRYPTO_TDES_CTRL, dev->mode);
>> +
>> +memcpy(dev->reg + RK_CRYPTO_TDES_IV_0, dev->ablk_req->info, 8);
> Please ensure that the IV is copied back after the operation.
> I know that many existing drivers are buggy in this regard but
> they will be fixed soon and we will start enforcing this rule
> so I don't want to add any new drivers that break this rule.
Thanks your responding, I will fix it in v5.
>
> Thanks,


--
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

[RFC PATCH 2/2] Crypto kernel tls socket

2015-11-23 Thread Dave Watson 
Userspace crypto interface for TLS.  Currently supports gcm(aes) 128bit only,
however the interface is the same as the rest of the SOCK_ALG interface, so it
should be possible to add more without any user interface changes.

Currently gcm(aes) represents ~80% of our SSL connections.

Userspace interface:

1) A transform and op socket are created using the userspace crypto interface
2) Setsockopt ALG_SET_AUTHSIZE is called
3) Setsockopt ALG_SET_KEY is called twice, since we need both send/recv keys
4) ALG_SET_IV cmsgs are sent twice, since we need both send/recv IVs.
   To support userspace heartbeats, changeciphersuite, etc, we would also need
   to get these back out, use them, then reset them via CMSG.
5) ALG_SET_OP cmsg is overloaded to mean FD to read/write from.

Example program:

https://github.com/djwatson/ktls

At a high level, this could be implemented on TCP sockets directly instead with
various tradeoffs.

The userspace crypto interface might benefit from some interface
tweaking to deal with multiple keys / ivs better.  The crypto accept()
op socket interface isn't a great fit, since there are never multiple
parallel operations.

There's also some questions around using skbuffs instead of scatterlists for
send/recv, and if we are buffering on recv, when we should be decrypting the
data.
---
 crypto/Kconfig |   12 +
 crypto/Makefile|1 +
 crypto/algif_tls.c | 1233 
 3 files changed, 1246 insertions(+)
 create mode 100644 crypto/algif_tls.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 7240821..c15638a 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1639,6 +1639,18 @@ config CRYPTO_USER_API_AEAD
  This option enables the user-spaces interface for AEAD
  cipher algorithms.

+config CRYPTO_USER_API_TLS
+   tristate "User-space interface for TLS net sockets"
+   depends on NET
+   select CRYPTO_AEAD
+   select CRYPTO_USER_API
+   help
+ This option enables kernel TLS socket framing
+ cipher algorithms.  TLS framing is added/removed and
+  chained to a TCP socket.  Handshake is done in
+  userspace.
+
+
 config CRYPTO_HASH_INFO
bool

diff --git a/crypto/Makefile b/crypto/Makefile
index f7aba92..fc26012 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
 obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
 obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
 obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
+obj-$(CONFIG_CRYPTO_USER_API_TLS) += algif_tls.o

 #
 # generic algorithms and the async_tx api
diff --git a/crypto/algif_tls.c b/crypto/algif_tls.c
new file mode 100644
index 000..123ade3
--- /dev/null
+++ b/crypto/algif_tls.c
@@ -0,0 +1,1233 @@
+/*
+ * algif_tls: User-space interface for TLS
+ *
+ * Copyright (C) 2015, Dave Watson 
+ *
+ * This file provides the user-space API for AEAD ciphers.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TLS_HEADER_SIZE 13
+#define TLS_TAG_SIZE 16
+#define TLS_IV_SIZE 8
+#define TLS_PADDED_AADLEN 16
+#define TLS_MAX_MESSAGE_LEN (1 << 14)
+
+/* Bytes not included in tls msg size field */
+#define TLS_FRAMING_SIZE 5
+
+#define TLS_APPLICATION_DATA_MSG 0x17
+#define TLS_VERSION 3
+
+struct tls_tfm_pair {
+   struct crypto_aead *tfm_send;
+   struct crypto_aead *tfm_recv;
+   int cur_setkey;
+};
+
+static struct workqueue_struct *tls_wq;
+
+struct tls_sg_list {
+   unsigned int cur;
+   struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+#define RSGL_MAX_ENTRIES ALG_MAX_PAGES
+
+struct tls_ctx {
+   /* Send and encrypted transmit buffers */
+   struct tls_sg_list tsgl;
+   struct scatterlist tcsgl[ALG_MAX_PAGES];
+
+   /* Encrypted receive and receive buffers. */
+   struct tls_sg_list rcsgl;
+   struct af_alg_sgl rsgl[RSGL_MAX_ENTRIES];
+
+   /* Sequence numbers. */
+   int iv_set;
+   void *iv_send;
+   void *iv_recv;
+
+   struct af_alg_completion completion;
+
+   /* Bytes to send */
+   unsigned long used;
+
+   /* padded */
+   size_t aead_assoclen;
+   /* unpadded */
+   size_t assoclen;
+   struct aead_request aead_req;
+   struct aead_request aead_resp;
+
+   bool more;
+   bool merge;
+
+   /* Chained TCP socket */
+   struct sock *sock;
+   struct socket *socket;
+
+   void (*save_data_ready)(struct sock *sk);
+   void (*save_write_space)(struct sock *sk);
+   void (*save_state_change)(struct sock *sk);
+   struct work_struct tx_work;
+

[RFC PATCH 0/2] Crypto kernel TLS socket

2015-11-23 Thread Dave Watson 
An approach for a kernel TLS socket.

Only the symmetric encryption / decryption is done in-kernel, as well
as minimal framing handling.  The handshake is kept in userspace, and
the negotiated cipher / keys / IVs are then set on the algif_tls
socket, which is then hooked in to a tcp socket using
sk_write_space/sk_data_ready hooks.

If a non application-data TLS record is seen, it is left on the TCP
socket and an error is returned on the ALG socket, and the record is
left for userspace to manage. Userspace can't ignore the message, but
could just close the socket.

TLS could potentially also be done directly on the TCP socket, but
seemed a bit harder to work with the OOB data for non application_data
messages, and the sockopts / CMSGS already exist for ALG sockets.  The
flip side is having to manage two fds in userspace.

Some reasons we're looking at this:

1) Access to sendfile/splice for CDN-type applications.  We were
   inspired by Netflix exploring this in FreeBSD

   https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

   For perf, this patch is almost on par with userspace OpenSSL.
   Currently there are some copies and allocs to support
   scatter/gather in aesni-intel_glue.c, but with some extra work to
   remove those (not included here), a sendfile() is faster than the
   equivalent userspace read/SSL_write using a 128k buffer by 2~7%.

2) Access to the unencrypted bytes in kernelspace.  For example, Tom
   Herbert's kcm would need this

   https://lwn.net/Articles/657999/

3) NIC offload. To support running aesni routines on the NIC instead
   of the processor, we would probably need enough of the framing
   interface put in kernel.


Dave Watson (2):
  Crypto support aesni rfc5288
  Crypto kernel tls socket

 arch/x86/crypto/aesni-intel_asm.S|6 +
 arch/x86/crypto/aesni-intel_avx-x86_64.S |4 +
 arch/x86/crypto/aesni-intel_glue.c   |  105 ++-
 crypto/Kconfig   |   12 +
 crypto/Makefile  |1 +
 crypto/algif_tls.c   | 1233 ++
 6 files changed, 1334 insertions(+), 27 deletions(-)
 create mode 100644 crypto/algif_tls.c

--
2.4.6
--
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

[RFC PATCH 1/2] Crypto support aesni rfc5288

2015-11-23 Thread Dave Watson 
Support rfc5288 using intel aesni routines.  See also rfc5246.

AAD length is 13 bytes padded out to 16. Padding bytes have to be
passed in in scatterlist currently, which probably isn't quite the
right fix.

The assoclen checks were moved to the individual rfc stubs, and the
common routines support all assoc lengths.

---
 arch/x86/crypto/aesni-intel_asm.S|   6 ++
 arch/x86/crypto/aesni-intel_avx-x86_64.S |   4 ++
 arch/x86/crypto/aesni-intel_glue.c   | 105 +++
 3 files changed, 88 insertions(+), 27 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 6bd2c6c..49667c4 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -228,6 +228,9 @@ XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
 MOVADQ SHUF_MASK(%rip), %xmm14
movarg7, %r10   # %r10 = AAD
movarg8, %r12   # %r12 = aadLen
+   add$3, %r12
+   and$~3, %r12
+
mov%r12, %r11
pxor   %xmm\i, %xmm\i

@@ -453,6 +456,9 @@ XMM2 XMM3 XMM4 XMMDst TMP6 TMP7 i i_seq operation
 MOVADQ SHUF_MASK(%rip), %xmm14
movarg7, %r10   # %r10 = AAD
movarg8, %r12   # %r12 = aadLen
+   add$3, %r12
+   and$~3, %r12
+
mov%r12, %r11
pxor   %xmm\i, %xmm\i
 _get_AAD_loop\num_initial_blocks\operation:
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S 
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index 522ab68..0756e4a 100644
--- a/arch/x86/crypto/aesni-intel_avx-x86_64.S
+++ b/arch/x86/crypto/aesni-intel_avx-x86_64.S
@@ -360,6 +360,8 @@ VARIABLE_OFFSET = 16*8

 mov arg6, %r10  # r10 = AAD
 mov arg7, %r12  # r12 = aadLen
+add $3, %r12
+and $~3, %r12


 mov %r12, %r11
@@ -1619,6 +1621,8 @@ ENDPROC(aesni_gcm_dec_avx_gen2)

 mov arg6, %r10   # r10 = AAD
 mov arg7, %r12   # r12 = aadLen
+add $3, %r12
+and $~3, %r12


 mov %r12, %r11
diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 3633ad6..00a42ca 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -949,12 +949,7 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
struct scatter_walk src_sg_walk;
struct scatter_walk dst_sg_walk;
unsigned int i;
-
-   /* Assuming we are supporting rfc4106 64-bit extended */
-   /* sequence numbers We need to have the AAD length equal */
-   /* to 16 or 20 bytes */
-   if (unlikely(req->assoclen != 16 && req->assoclen != 20))
-   return -EINVAL;
+   unsigned int padded_assoclen = (req->assoclen + 3) & ~3;

/* IV below built */
for (i = 0; i < 4; i++)
@@ -970,21 +965,21 @@ static int helper_rfc4106_encrypt(struct aead_request 
*req)
one_entry_in_sg = 1;
scatterwalk_start(_sg_walk, req->src);
assoc = scatterwalk_map(_sg_walk);
-   src = assoc + req->assoclen;
+   src = assoc + padded_assoclen;
dst = src;
if (unlikely(req->src != req->dst)) {
scatterwalk_start(_sg_walk, req->dst);
-   dst = scatterwalk_map(_sg_walk) + req->assoclen;
+   dst = scatterwalk_map(_sg_walk) + padded_assoclen;
}
} else {
/* Allocate memory for src, dst, assoc */
-   assoc = kmalloc(req->cryptlen + auth_tag_len + req->assoclen,
+   assoc = kmalloc(req->cryptlen + auth_tag_len + padded_assoclen,
GFP_ATOMIC);
if (unlikely(!assoc))
return -ENOMEM;
scatterwalk_map_and_copy(assoc, req->src, 0,
-req->assoclen + req->cryptlen, 0);
-   src = assoc + req->assoclen;
+padded_assoclen + req->cryptlen, 0);
+   src = assoc + padded_assoclen;
dst = src;
}

@@ -998,7 +993,7 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
 * back to the packet. */
if (one_entry_in_sg) {
if (unlikely(req->src != req->dst)) {
-   scatterwalk_unmap(dst - req->assoclen);
+   scatterwalk_unmap(dst - padded_assoclen);
scatterwalk_advance(_sg_walk, req->dst->length);
scatterwalk_done(_sg_walk, 1, 0);
}
@@ -1006,7 +1001,7 @@ static int helper_rfc4106_encrypt(struct aead_request 
*req)
scatterwalk_advance(_sg_walk, req->src->length);
scatterwalk_done(_sg_walk,

Re: [RFC PATCH 2/2] Crypto kernel tls socket

2015-11-23 Thread Dave Watson 
On 11/23/15 02:27 PM, Sowmini Varadhan wrote:
> On (11/23/15 09:43), Dave Watson wrote:
> > Currently gcm(aes) represents ~80% of our SSL connections.
> >
> > Userspace interface:
> >
> > 1) A transform and op socket are created using the userspace crypto 
> > interface
> > 2) Setsockopt ALG_SET_AUTHSIZE is called
> > 3) Setsockopt ALG_SET_KEY is called twice, since we need both send/recv keys
> > 4) ALG_SET_IV cmsgs are sent twice, since we need both send/recv IVs.
> >To support userspace heartbeats, changeciphersuite, etc, we would also 
> > need
> >to get these back out, use them, then reset them via CMSG.
> > 5) ALG_SET_OP cmsg is overloaded to mean FD to read/write from.
>
> [from patch 0/2:]
> > If a non application-data TLS record is seen, it is left on the TCP
> > socket and an error is returned on the ALG socket, and the record is
> > left for userspace to manage.
>
> I'm trying to see how your approach would fit with the RDS-type of
> use-case. RDS-TCP is mostly similar in concept to kcm,
> except that rds has its own header for multiplexing, and has no
> dependancy on BPF for basic things like re-assembling the datagram.
> If I were to try to use this for RDS-TCP, the tls_tcp_read_sock() logic
> would be merged into the recv_actor callback for RDS, right?  Thus tls
> control-plane message could be seen in the middle of the
> data-stream, so we really have to freeze the processing of the data
> stream till the control-plane message is processed?

Correct.

> In the tls.c example that you have, the opfd is generated from
> the accept() on the AF_ALG socket- how would this work if I wanted
> my opfd to be a PF_RDS or a PF_KCM or similar?

For kcm, opfd is the fd you would pass along in kcm_attach.

For rds, it looks like you'd want to use opfd as the sock instead of
the new one created by sock_create_kern in rds_tcp_conn_connect.

> One concern is that this patchset provides a solution for the "80%"
> case but what about the other 20% (and the non x86 platforms)?

Almost all the rest are aes sha.  The actual encrypt / decrypt code
would be similar to this previous patch:

http://marc.info/?l=linux-kernel=140662647602192=2

The software routines in gcm(aes) should work for all platforms
without aesni.

> E.g., if I get a cipher-suite request outside the aes-ni, what would
> happen (punt to uspace?)
>
> --Sowmini

Right, bind() would fail and you would fallback to uspace.
--
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