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
