Re: [PATCH 1/2] dt/bindings: Add bindings for hisilicon random number generator
On Fri, Apr 01, 2016 at 09:37:43AM +0800, Kefeng Wang wrote: > Document the devicetree bindings for the random number generator > found on Hisilicon Hip04 and Hip05 soc. > > Signed-off-by: Kefeng Wang > --- > Documentation/devicetree/bindings/rng/hisi-rng.txt | 12 > 1 file changed, 12 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rng/hisi-rng.txt > > diff --git a/Documentation/devicetree/bindings/rng/hisi-rng.txt > b/Documentation/devicetree/bindings/rng/hisi-rng.txt > new file mode 100644 > index 000..80f29b6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rng/hisi-rng.txt > @@ -0,0 +1,12 @@ > +Hisilicon Random Number Generator > + > +Required properties: > +- compatible : Should be "hisilicon,hisi-rng" hisi is a bit redundant with hisilicon and please define SoC specific compatible strings. > +- reg : Offset and length of the register set of this block > + > +Example: > + > +rng@d101 { > + compatible = "hisilicon,hisi-rng"; > + reg = <0xd101 0x100>; > +}; > -- > 1.7.12.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] sunrpc: Fix skcipher/shash conversion
On Mon, Apr 04, 2016 at 09:22:02AM +0800, Herbert Xu wrote: > On Sun, Apr 03, 2016 at 06:15:43PM -0400, J. Bruce Fields wrote: > > For some reason, the original didn't appear to get cc'd to the linux-nfs > > list. Or did it, and I missed it? I do get lazy sometimes, but in > > general something like this I'd at least grab and run some tests on. > > Especially if there's a git tree I can grab, then it just takes me a > > minute to kick off. > > I'm pretty sure it did get to linux-nfs, or at least the archive :) > > https://www.spinics.net/lists/linux-nfs/msg56240.html D'oh. I was probably just lame, then. Thanks for the fix. Feel free to add my tested-by: if you want. Hm, now I'm seeing list corruption in the rpc code on callbacks That's almost certainly unrelated to this, though. --b. -- 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] sunrpc: Fix skcipher/shash conversion
On Sun, Apr 03, 2016 at 06:15:43PM -0400, J. Bruce Fields wrote: > > OK, I did get a chance to run this, and so far it looks good--it got > faszter than the last time, anyway. Thanks! Thanks! > For some reason, the original didn't appear to get cc'd to the linux-nfs > list. Or did it, and I missed it? I do get lazy sometimes, but in > general something like this I'd at least grab and run some tests on. > Especially if there's a git tree I can grab, then it just takes me a > minute to kick off. I'm pretty sure it did get to linux-nfs, or at least the archive :) https://www.spinics.net/lists/linux-nfs/msg56240.html Cheers, -- 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] sunrpc: Fix skcipher/shash conversion
On Sun, Apr 03, 2016 at 12:37:15PM +0800, Herbert Xu wrote: > On Sat, Apr 02, 2016 at 11:59:00PM -0400, J. Bruce Fields wrote: > > > > Thanks. It's getting further now, but appears to be freezing later. > > Possibly unrelated. I'm travelling, and it'll be Monday or Wednesday > > till I can take another look. > > Thanks for the update. I've found another bug in the hash conversion > that causes memory corruption which may lead to your hang. > > Here's a patch with the previous fix plus the new hash fixes. OK, I did get a chance to run this, and so far it looks good--it got faszter than the last time, anyway. Thanks! For some reason, the original didn't appear to get cc'd to the linux-nfs list. Or did it, and I missed it? I do get lazy sometimes, but in general something like this I'd at least grab and run some tests on. Especially if there's a git tree I can grab, then it just takes me a minute to kick off. --b. > > ---8<--- > The skcpiher/shash conversion introduced a number of bugs in the > sunrpc code: > > 1) Missing calls to skcipher_request_set_tfm lead to crashes. > 2) The allocation size of shash_desc is too small which leads to > memory corruption. > > Fixes: 3b5cf20cf439 ("sunrpc: Use skcipher and ahash/shash") > Reported-by: J. Bruce Fields > Signed-off-by: Herbert Xu > > diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c > b/net/sunrpc/auth_gss/gss_krb5_crypto.c > index d94a8e1..da26455 100644 > --- a/net/sunrpc/auth_gss/gss_krb5_crypto.c > +++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c > @@ -78,6 +78,7 @@ krb5_encrypt( > memcpy(out, in, length); > sg_init_one(sg, out, length); > > + skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); > skcipher_request_set_crypt(req, sg, sg, length, local_iv); > > @@ -115,6 +116,7 @@ krb5_decrypt( > memcpy(out, in, length); > sg_init_one(sg, out, length); > > + skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); > skcipher_request_set_crypt(req, sg, sg, length, local_iv); > > @@ -946,7 +948,8 @@ krb5_rc4_setup_seq_key(struct krb5_ctx *kctx, struct > crypto_skcipher *cipher, > return PTR_ERR(hmac); > } > > - desc = kmalloc(sizeof(*desc), GFP_KERNEL); > + desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac), > +GFP_KERNEL); > if (!desc) { > dprintk("%s: failed to allocate shash descriptor for '%s'\n", > __func__, kctx->gk5e->cksum_name); > @@ -1012,7 +1015,8 @@ krb5_rc4_setup_enc_key(struct krb5_ctx *kctx, struct > crypto_skcipher *cipher, > return PTR_ERR(hmac); > } > > - desc = kmalloc(sizeof(*desc), GFP_KERNEL); > + desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac), > +GFP_KERNEL); > if (!desc) { > dprintk("%s: failed to allocate shash descriptor for '%s'\n", > __func__, kctx->gk5e->cksum_name); > diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c > b/net/sunrpc/auth_gss/gss_krb5_mech.c > index 71341cc..6542749 100644 > --- a/net/sunrpc/auth_gss/gss_krb5_mech.c > +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c > @@ -451,7 +451,8 @@ context_derive_keys_rc4(struct krb5_ctx *ctx) > goto out_err_free_hmac; > > > - desc = kmalloc(sizeof(*desc), GFP_KERNEL); > + desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac), > +GFP_KERNEL); > if (!desc) { > dprintk("%s: failed to allocate hash descriptor for '%s'\n", > __func__, ctx->gk5e->cksum_name); > -- > 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: What are the requirements to create/open an AF_ALG socket type?
On Sun, Apr 3, 2016 at 4:42 PM, Jeffrey Walton wrote: > I'm testing userspace crypto code using AF_ALG domain socket. The call > to 'socket(AF_ALG, SOCK_SEQPACKET, 0)' always fails with errno=2. The > failure has been experienced on 3.8, 4.1, 4.2 and 4.4 kernels > (provided by Debian, Fedora, Lubuntu and Ubuntu). I also experienced > it on a Gentoo kernel, but I don't recall the kernel version. I've > checked the kernel configs, and they all include > "CONFIG_CRYPTO_USER_API={y|m}". > > When similar code is called from userland using the async crypto gear, > then the call to socket usually succeeds. During async testing, I also > see a dmesg about registering a socket family 38. The dmesg is not > present during the non-async failures. > > I also checked the kernel crypto documentation at > http://www.kernel.org/doc/Documentation/crypto/ and > http://www.kernel.org/doc/htmldocs/crypto-API/User.html, but I don't > see a requirement I might be missing. I also checked a couple of slide > decks introducing the userspace crypto API, and I don't see what the > presenters are doing differently. Finally, I checked the LVN example > provided at http://lwn.net/Articles/410848/. > > If it matters, I usually disable IPv6 via a boot parameter since I > don't use it in my environments. But I'm guessing it has nothing to do > with the problem since the async gear works fine. > > What are the requirements to create/open an AF_ALG socket? > > Or maybe, what is missing so the call to socket succeeds? Cancel...My apologies... The call to bind() was failing after the socket was created. Mis-identifying socket() was due to a copy/paste of the error logic. The bind failure was due to .salg_type = "hmac" with .salg_name = "sha512". Jeff -- 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
What are the requirements to create/open an AF_ALG socket type?
I'm testing userspace crypto code using AF_ALG domain socket. The call to 'socket(AF_ALG, SOCK_SEQPACKET, 0)' always fails with errno=2. The failure has been experienced on 3.8, 4.1, 4.2 and 4.4 kernels (provided by Debian, Fedora, Lubuntu and Ubuntu). I also experienced it on a Gentoo kernel, but I don't recall the kernel version. I've checked the kernel configs, and they all include "CONFIG_CRYPTO_USER_API={y|m}". When similar code is called from userland using the async crypto gear, then the call to socket usually succeeds. During async testing, I also see a dmesg about registering a socket family 38. The dmesg is not present during the non-async failures. I also checked the kernel crypto documentation at http://www.kernel.org/doc/Documentation/crypto/ and http://www.kernel.org/doc/htmldocs/crypto-API/User.html, but I don't see a requirement I might be missing. I also checked a couple of slide decks introducing the userspace crypto API, and I don't see what the presenters are doing differently. Finally, I checked the LVN example provided at http://lwn.net/Articles/410848/. If it matters, I usually disable IPv6 via a boot parameter since I don't use it in my environments. But I'm guessing it has nothing to do with the problem since the async gear works fine. What are the requirements to create/open an AF_ALG socket? Or maybe, what is missing so the call to socket succeeds? Thanks in advance. ** #include #include #include #include #include int main(int argc, char* argv[]) { s = socket(AF_ALG, SOCK_SEQPACKET, 0); if (s == -1) { fprintf(stderr, "Failed to open socket: %d\n", errno); goto cleanup; } ... } -- 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] hwrng: bcm63xx - fix device tree compilation
Adds missing include that resulted in implicit device tree functions errors. Fixes: 7b651706712b ("hwrng: bcm63xx - add device tree support") Signed-off-by: Álvaro Fernández Rojas --- drivers/char/hw_random/bcm63xx-rng.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/bcm63xx-rng.c b/drivers/char/hw_random/bcm63xx-rng.c index ca9c403..5132c9c 100644 --- a/drivers/char/hw_random/bcm63xx-rng.c +++ b/drivers/char/hw_random/bcm63xx-rng.c @@ -12,6 +12,7 @@ #include #include #include +#include #define RNG_CTRL 0x00 #define RNG_EN (1 << 0) -- 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