* crypto: caam warning fix, was: master build: 0 failures 1 warnings (v4.9-rc5-177-g81bcfe5)
From: Arnd Bergmann @ 2016-11-16 16:40 UTC (permalink / raw)
To: linaro-kernel
Cc: Build bot for Mark Brown, kernel-build-reports, Horia Geantă,
Herbert Xu, linux-crypto
In-Reply-To: <E1c6kSQ-0008UC-DM@optimist>
On Tuesday, November 15, 2016 8:35:54 PM CET Build bot for Mark Brown wrote:
> Tree/Branch: master
> Git describe: v4.9-rc5-177-g81bcfe5
> Commit: 81bcfe5e48 Merge tag 'trace-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
>
> Build Time: 87 min 40 sec
>
> Passed: 10 / 10 (100.00 %)
> Failed: 0 / 10 ( 0.00 %)
>
> Errors: 0
> Warnings: 1
> Section Mismatches: 0
>
> -------------------------------------------------------------------------------
> defconfigs with issues (other than build errors):
> 1 warnings 0 mismatches : arm64-allmodconfig
>
> -------------------------------------------------------------------------------
>
> Warnings Summary: 1
> 1 ../include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
>
Hi Herbert,
This is currently the only build warning reported for v4.9, and you have merged
the fix for v4.10 in
d69985a07692 ("crypto: caam - fix type mismatch warning")
Any chance you can send this for v4.9 so we have a clean build?
Thanks,
Arnd
^ permalink raw reply
* [PATCH] powerpc: crypto/vmx: various build fixes
From: Naveen N. Rao @ 2016-11-16 15:11 UTC (permalink / raw)
To: Leonidas S. Barbosa, Herbert Xu, Michael Ellerman
Cc: Paulo Flabiano Smorigo, linux-crypto, linuxppc-dev
First up, clean up the generated .S files properly on a 'make clean'.
Secondly, force re-generation of these files when building for different
endian-ness than what was built previously. Finally, generate the new
files in the build tree, rather than the source tree.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
Michael,
I've added your SOB here though you didn't explicitly include it in your
previous mail. I hope that's fine from your end.
- Naveen
drivers/crypto/vmx/Makefile | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index de6e241..55f7c39 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -10,10 +10,12 @@ endif
quiet_cmd_perl = PERL $@
cmd_perl = $(PERL) $(<) $(TARGET) > $(@)
-$(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
- $(call cmd,perl)
+targets += aesp8-ppc.S ghashp8-ppc.S
+
+$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
+ $(call if_changed,perl)
-$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
- $(call cmd,perl)
+$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
+ $(call if_changed,perl)
-.PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
+clean-files := aesp8-ppc.S ghashp8-ppc.S
--
2.10.2
^ permalink raw reply related
* Re: [RFC PATCH] powerpc: crypto/vmx: clean up generated files
From: Naveen N. Rao @ 2016-11-16 11:27 UTC (permalink / raw)
To: Michael Ellerman
Cc: Leonidas S. Barbosa, linuxppc-dev, Herbert Xu,
Paulo Flabiano Smorigo, linux-crypto
In-Reply-To: <87oa1fyc7s.fsf@concordia.ellerman.id.au>
On 2016/11/16 09:02PM, Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>
> > ..as stray .S files result in build errors, especially when using
> > cross-compilers.
>
> They should be cleaned on make clean, so adding them to clean-files
> seems correct.
>
> > More specifically, the generated .S files are endian-specific and will break
> > subsequent builds targeting the other endian architecture.
>
> But that indicates we're missing an if_changed somewhere, ie. switching
> endian should cause them to be regenerated.
>
> Also they should be generated into $(obj) not $(src) I think.
>
> How about this?
Nice!
>
> diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
> index de6e241..52f6ae9 100644
> --- a/drivers/crypto/vmx/Makefile
> +++ b/drivers/crypto/vmx/Makefile
> @@ -10,10 +10,10 @@ endif
> quiet_cmd_perl = PERL $@
> cmd_perl = $(PERL) $(<) $(TARGET) > $(@)
>
Looks like we also need:
targets += aesp8-ppc.S ghashp8-ppc.S
> -$(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
> - $(call cmd,perl)
> +$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
> + $(call if_changed,perl)
>
> -$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
> - $(call cmd,perl)
> +$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
> + $(call if_changed,perl)
>
> .PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
I will send a v2 with these changes.
Thanks,
Naveen
^ permalink raw reply
* RE: [PATCH] crypto: add virtio-crypto driver
From: Gonglei (Arei) @ 2016-11-16 10:09 UTC (permalink / raw)
To: Gonglei (Arei), qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linux-crypto@vger.kernel.org
Cc: Luonengjun, mst@redhat.com, stefanha@redhat.com, Huangweidong (C),
Wubin (H), xin.zeng@intel.com, Claudio Fontana,
herbert@gondor.apana.org.au, pasic@linux.vnet.ibm.com,
davem@davemloft.net, Zhoujian (jay, Euler), Hanweidong (Randy),
Huangpeng (Peter), arei.gonglei@hotmail.com,
cornelia.huck@de.ibm.com, Xuquan (Quan Xu)
In-Reply-To: <1479106074-32036-1-git-send-email-arei.gonglei@huawei.com>
Hi Michael,
May I should convert all __virtio32/64 to le32/64 in virtio_crypto.h ?
> +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
> +
> +struct virtio_crypto_ctrl_header {
> +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
> +#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
> +#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
> +#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
> +#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
> +#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
> +#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
> +#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
> + __virtio32 opcode;
> + __virtio32 algo;
> + __virtio32 flag;
> + /* data virtqueue id */
> + __virtio32 queue_id;
> +};
> +
> +struct virtio_crypto_cipher_session_para {
> +#define VIRTIO_CRYPTO_NO_CIPHER 0
> +#define VIRTIO_CRYPTO_CIPHER_ARC4 1
> +#define VIRTIO_CRYPTO_CIPHER_AES_ECB 2
> +#define VIRTIO_CRYPTO_CIPHER_AES_CBC 3
> +#define VIRTIO_CRYPTO_CIPHER_AES_CTR 4
> +#define VIRTIO_CRYPTO_CIPHER_DES_ECB 5
> +#define VIRTIO_CRYPTO_CIPHER_DES_CBC 6
> +#define VIRTIO_CRYPTO_CIPHER_3DES_ECB 7
> +#define VIRTIO_CRYPTO_CIPHER_3DES_CBC 8
> +#define VIRTIO_CRYPTO_CIPHER_3DES_CTR 9
> +#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8 10
> +#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA2 11
> +#define VIRTIO_CRYPTO_CIPHER_AES_F8 12
> +#define VIRTIO_CRYPTO_CIPHER_AES_XTS 13
> +#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3 14
> + __virtio32 algo;
> + /* length of key */
> + __virtio32 keylen;
> +
> +#define VIRTIO_CRYPTO_OP_ENCRYPT 1
> +#define VIRTIO_CRYPTO_OP_DECRYPT 2
> + /* encrypt or decrypt */
> + __virtio32 op;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_session_input {
> + /* Device-writable part */
> + __virtio64 session_id;
> + __virtio32 status;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_cipher_session_req {
> + struct virtio_crypto_cipher_session_para para;
> +};
> +
> +struct virtio_crypto_hash_session_para {
> +#define VIRTIO_CRYPTO_NO_HASH 0
> +#define VIRTIO_CRYPTO_HASH_MD5 1
> +#define VIRTIO_CRYPTO_HASH_SHA1 2
> +#define VIRTIO_CRYPTO_HASH_SHA_224 3
> +#define VIRTIO_CRYPTO_HASH_SHA_256 4
> +#define VIRTIO_CRYPTO_HASH_SHA_384 5
> +#define VIRTIO_CRYPTO_HASH_SHA_512 6
> +#define VIRTIO_CRYPTO_HASH_SHA3_224 7
> +#define VIRTIO_CRYPTO_HASH_SHA3_256 8
> +#define VIRTIO_CRYPTO_HASH_SHA3_384 9
> +#define VIRTIO_CRYPTO_HASH_SHA3_512 10
> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE128 11
> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE256 12
> + __virtio32 algo;
> + /* hash result length */
> + __virtio32 hash_result_len;
> +};
> +
> +struct virtio_crypto_hash_create_session_req {
> + struct virtio_crypto_hash_session_para para;
> +};
> +
> +struct virtio_crypto_mac_session_para {
> +#define VIRTIO_CRYPTO_NO_MAC 0
> +#define VIRTIO_CRYPTO_MAC_HMAC_MD5 1
> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA1 2
> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_224 3
> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_256 4
> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_384 5
> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_512 6
> +#define VIRTIO_CRYPTO_MAC_CMAC_3DES 25
> +#define VIRTIO_CRYPTO_MAC_CMAC_AES 26
> +#define VIRTIO_CRYPTO_MAC_KASUMI_F9 27
> +#define VIRTIO_CRYPTO_MAC_SNOW3G_UIA2 28
> +#define VIRTIO_CRYPTO_MAC_GMAC_AES 41
> +#define VIRTIO_CRYPTO_MAC_GMAC_TWOFISH 42
> +#define VIRTIO_CRYPTO_MAC_CBCMAC_AES 49
> +#define VIRTIO_CRYPTO_MAC_CBCMAC_KASUMI_F9 50
> +#define VIRTIO_CRYPTO_MAC_XCBC_AES 53
> + __virtio32 algo;
> + /* hash result length */
> + __virtio32 hash_result_len;
> + /* length of authenticated key */
> + __virtio32 auth_key_len;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_mac_create_session_req {
> + struct virtio_crypto_mac_session_para para;
> +};
> +
> +struct virtio_crypto_aead_session_para {
> +#define VIRTIO_CRYPTO_NO_AEAD 0
> +#define VIRTIO_CRYPTO_AEAD_GCM 1
> +#define VIRTIO_CRYPTO_AEAD_CCM 2
> +#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305 3
> + __virtio32 algo;
> + /* length of key */
> + __virtio32 key_len;
> + /* hash result length */
> + __virtio32 hash_result_len;
> + /* length of the additional authenticated data (AAD) in bytes */
> + __virtio32 aad_len;
> + /* encrypt or decrypt, See above VIRTIO_CRYPTO_OP_* */
> + __virtio32 op;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_aead_create_session_req {
> + struct virtio_crypto_aead_session_para para;
> +};
> +
> +struct virtio_crypto_alg_chain_session_para {
> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_HASH_THEN_CIPHER 1
> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_CIPHER_THEN_HASH 2
> + __virtio32 alg_chain_order;
> +/* Plain hash */
> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN 1
> +/* Authenticated hash (mac) */
> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH 2
> +/* Nested hash */
> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_NESTED 3
> + __virtio32 hash_mode;
> + struct virtio_crypto_cipher_session_para cipher_param;
> + union {
> + struct virtio_crypto_hash_session_para hash_param;
> + struct virtio_crypto_mac_session_para mac_param;
> + } u;
> + /* length of the additional authenticated data (AAD) in bytes */
> + __virtio32 aad_len;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_alg_chain_session_req {
> + struct virtio_crypto_alg_chain_session_para para;
> +};
> +
> +struct virtio_crypto_sym_create_session_req {
> + union {
> + struct virtio_crypto_cipher_session_req cipher;
> + struct virtio_crypto_alg_chain_session_req chain;
> + } u;
> +
> + /* Device-readable part */
> +
> +/* No operation */
> +#define VIRTIO_CRYPTO_SYM_OP_NONE 0
> +/* Cipher only operation on the data */
> +#define VIRTIO_CRYPTO_SYM_OP_CIPHER 1
> +/*
> + * Chain any cipher with any hash or mac operation. The order
> + * depends on the value of alg_chain_order param
> + */
> +#define VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING 2
> + __virtio32 op_type;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_destroy_session_req {
> + /* Device-readable part */
> + __virtio64 session_id;
> +};
> +
> +/* The request of the control viritqueue's packet */
> +struct virtio_crypto_op_ctrl_req {
> + struct virtio_crypto_ctrl_header header;
> +
> + union {
> + struct virtio_crypto_sym_create_session_req
> + sym_create_session;
> + struct virtio_crypto_hash_create_session_req
> + hash_create_session;
> + struct virtio_crypto_mac_create_session_req
> + mac_create_session;
> + struct virtio_crypto_aead_create_session_req
> + aead_create_session;
> + struct virtio_crypto_destroy_session_req
> + destroy_session;
> + } u;
> +};
> +
> +struct virtio_crypto_op_header {
> +#define VIRTIO_CRYPTO_CIPHER_ENCRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x00)
> +#define VIRTIO_CRYPTO_CIPHER_DECRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x01)
> +#define VIRTIO_CRYPTO_HASH \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x00)
> +#define VIRTIO_CRYPTO_MAC \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x00)
> +#define VIRTIO_CRYPTO_AEAD_ENCRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> +#define VIRTIO_CRYPTO_AEAD_DECRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> + __virtio32 opcode;
> + /* algo should be service-specific algorithms */
> + __virtio32 algo;
> + /* session_id should be service-specific algorithms */
> + __virtio64 session_id;
> + /* control flag to control the request */
> + __virtio32 flag;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_cipher_para {
> + /*
> + * Byte Length of valid IV/Counter
> + *
> + * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> + * SNOW3G in UEA2 mode, this is the length of the IV (which
> + * must be the same as the block length of the cipher).
> + * For block ciphers in CTR mode, this is the length of the counter
> + * (which must be the same as the block length of the cipher).
> + * For AES-XTS, this is the 128bit tweak, i, from IEEE Std 1619-2007.
> + *
> + * The IV/Counter will be updated after every partial cryptographic
> + * operation.
> + */
> + __virtio32 iv_len;
> + /* length of source data */
> + __virtio32 src_data_len;
> + /* length of dst data */
> + __virtio32 dst_data_len;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_hash_para {
> + /* length of source data */
> + __virtio32 src_data_len;
> + /* hash result length */
> + __virtio32 hash_result_len;
> +};
> +
> +struct virtio_crypto_mac_para {
> + struct virtio_crypto_hash_para hash;
> +};
> +
> +struct virtio_crypto_aead_para {
> + /*
> + * Byte Length of valid IV data pointed to by the below iv_addr
> + * parameter.
> + *
> + * For GCM mode, this is either 12 (for 96-bit IVs) or 16, in which
> + * case iv_addr points to J0.
> + * For CCM mode, this is the length of the nonce, which can be in the
> + * range 7 to 13 inclusive.
> + */
> + __virtio32 iv_len;
> + /* length of additional auth data */
> + __virtio32 aad_len;
> + /* length of source data */
> + __virtio32 src_data_len;
> + /* length of dst data */
> + __virtio32 dst_data_len;
> +};
> +
> +struct virtio_crypto_cipher_data_req {
> + /* Device-readable part */
> + struct virtio_crypto_cipher_para para;
> +};
> +
> +struct virtio_crypto_hash_data_req {
> + /* Device-readable part */
> + struct virtio_crypto_hash_para para;
> +};
> +
> +struct virtio_crypto_mac_data_req {
> + /* Device-readable part */
> + struct virtio_crypto_mac_para para;
> +};
> +
> +struct virtio_crypto_alg_chain_data_para {
> + __virtio32 iv_len;
> + /* Length of source data */
> + __virtio32 src_data_len;
> + /* Length of destination data */
> + __virtio32 dst_data_len;
> + /* Starting point for cipher processing in source data */
> + __virtio32 cipher_start_src_offset;
> + /* Length of the source data that the cipher will be computed on */
> + __virtio32 len_to_cipher;
> + /* Starting point for hash processing in source data */
> + __virtio32 hash_start_src_offset;
> + /* Length of the source data that the hash will be computed on */
> + __virtio32 len_to_hash;
> + /* Length of the additional auth data */
> + __virtio32 aad_len;
> + /* Length of the hash result */
> + __virtio32 hash_result_len;
> + __virtio32 reserved;
> +};
> +
> +struct virtio_crypto_alg_chain_data_req {
> + /* Device-readable part */
> + struct virtio_crypto_alg_chain_data_para para;
> +};
> +
> +struct virtio_crypto_sym_data_req {
> + union {
> + struct virtio_crypto_cipher_data_req cipher;
> + struct virtio_crypto_alg_chain_data_req chain;
> + } u;
> +
> + /* See above VIRTIO_CRYPTO_SYM_OP_* */
> + __virtio32 op_type;
> + __virtio32 padding;
> +};
> +
> +struct virtio_crypto_aead_data_req {
> + /* Device-readable part */
> + struct virtio_crypto_aead_para para;
> +};
> +
> +/* The request of the data viritqueue's packet */
> +struct virtio_crypto_op_data_req {
> + struct virtio_crypto_op_header header;
> +
> + union {
> + struct virtio_crypto_sym_data_req sym_req;
> + struct virtio_crypto_hash_data_req hash_req;
> + struct virtio_crypto_mac_data_req mac_req;
> + struct virtio_crypto_aead_data_req aead_req;
> + } u;
> +};
> +
> +#define VIRTIO_CRYPTO_OK 0
> +#define VIRTIO_CRYPTO_ERR 1
> +#define VIRTIO_CRYPTO_BADMSG 2
> +#define VIRTIO_CRYPTO_NOTSUPP 3
> +#define VIRTIO_CRYPTO_INVSESS 4 /* Invaild session id */
> +
> +/* The accelerator hardware is ready */
> +#define VIRTIO_CRYPTO_S_HW_READY (1 << 0)
> +#define VIRTIO_CRYPTO_S_STARTED (1 << 1)
> +
> +struct virtio_crypto_config {
> + /* See VIRTIO_CRYPTO_OP_* above */
> + __virtio32 status;
> +
> + /*
> + * Maximum number of data queue legal values are between 1 and
> 0x8000
> + */
> + __virtio32 max_dataqueues;
> +
> + /*
> + * Specifies the services mask which the devcie support,
> + * see VIRTIO_CRYPTO_SERVICE_* above
> + */
> + __virtio32 crypto_services;
> +
> + /* Detailed algorithms mask */
> + __virtio32 cipher_algo_l;
> + __virtio32 cipher_algo_h;
> + __virtio32 hash_algo;
> + __virtio32 mac_algo_l;
> + __virtio32 mac_algo_h;
> + __virtio32 aead_algo;
> + /* Maximum length of cipher key */
> + __virtio32 max_cipher_key_len;
> + /* Maximum length of authenticated key */
> + __virtio32 max_auth_key_len;
> + __virtio32 reserve;
> + /* Maximum size of each crypto request's content */
> + __virtio64 max_size;
> +};
> +
^ permalink raw reply
* Re: [RFC PATCH] powerpc: crypto/vmx: clean up generated files
From: Michael Ellerman @ 2016-11-16 10:02 UTC (permalink / raw)
To: Naveen N. Rao, Leonidas S. Barbosa, Herbert Xu
Cc: Paulo Flabiano Smorigo, linux-crypto, linuxppc-dev
In-Reply-To: <20161115170549.10538-1-naveen.n.rao@linux.vnet.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> ..as stray .S files result in build errors, especially when using
> cross-compilers.
They should be cleaned on make clean, so adding them to clean-files
seems correct.
> More specifically, the generated .S files are endian-specific and will break
> subsequent builds targeting the other endian architecture.
But that indicates we're missing an if_changed somewhere, ie. switching
endian should cause them to be regenerated.
Also they should be generated into $(obj) not $(src) I think.
How about this?
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index de6e241..52f6ae9 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -10,10 +10,10 @@ endif
quiet_cmd_perl = PERL $@
cmd_perl = $(PERL) $(<) $(TARGET) > $(@)
-$(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
- $(call cmd,perl)
+$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
+ $(call if_changed,perl)
-$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
- $(call cmd,perl)
+$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
+ $(call if_changed,perl)
.PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
cheers
^ permalink raw reply related
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Herbert Xu @ 2016-11-16 9:05 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <2184005.6LaQaNuGm1@positron.chronox.de>
On Wed, Nov 16, 2016 at 10:02:59AM +0100, Stephan Mueller wrote:
> Am Mittwoch, 16. November 2016, 16:57:42 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Tue, Nov 15, 2016 at 08:06:47PM +0100, Stephan Mueller wrote:
> > > Shall the fix be rolled into the patch together with the fix for the tag
> > > value as well as the crash fix? Or can we have a stand-alone patch fixing
> > > this.
> > I think these are two separate issues and we don't need to fix them
> > all in one go.
>
> I will resubmit the patches regarding the tag and the bug fix then.
Also if we go the route of doing the copy in algif_aead then we don't
need to touch the crypto code at all.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Herbert Xu @ 2016-11-16 9:04 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <2184005.6LaQaNuGm1@positron.chronox.de>
On Wed, Nov 16, 2016 at 10:02:59AM +0100, Stephan Mueller wrote:
>
> One thing occurred to me: The copying of the AD would only be done of src !=
> dst. For the AF_ALG interface, I thing we always have src != dst due to the
> user space/kernel space translation. That means the kernel copies the AD
> around even in user space src == dst. Isn't that a waste? I.e. shouldn't we
> handle the AD copying rather in user space than in kernel space?
No that's not the case. You can do zero-copy, in which case src
would be identical to dst.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Stephan Mueller @ 2016-11-16 9:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <20161116085742.GA29644@gondor.apana.org.au>
Am Mittwoch, 16. November 2016, 16:57:42 CET schrieb Herbert Xu:
Hi Herbert,
> On Tue, Nov 15, 2016 at 08:06:47PM +0100, Stephan Mueller wrote:
> > Shall the fix be rolled into the patch together with the fix for the tag
> > value as well as the crash fix? Or can we have a stand-alone patch fixing
> > this.
> I think these are two separate issues and we don't need to fix them
> all in one go.
I will resubmit the patches regarding the tag and the bug fix then.
>
> > Btw., how do you suggest that should be fixed? I would assume that this
> > needs to be fixed on a per-implementation basis. I tested authenc and it
> > copies the buffers over. gcm_base(ctr-aes-aesni,ghash-clmulni),
> > rfc4106-gcm-aesni or ccm_base(ctr-aes-aesni,aes-aesni) do not copy the AD
> > over.
>
> We should fix as much as we can and then add a testmgr test to find
> the rest.
One thing occurred to me: The copying of the AD would only be done of src !=
dst. For the AF_ALG interface, I thing we always have src != dst due to the
user space/kernel space translation. That means the kernel copies the AD
around even in user space src == dst. Isn't that a waste? I.e. shouldn't we
handle the AD copying rather in user space than in kernel space?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix handling of RSA exponent on a v5 device
From: Herbert Xu @ 2016-11-16 9:01 UTC (permalink / raw)
To: Gary R Hook; +Cc: Gary R Hook, linux-crypto, thomas.lendacky, davem
In-Reply-To: <60b38fe7-e08e-05c4-8316-e2408bef2f33@amd.com>
On Tue, Nov 15, 2016 at 03:41:25PM -0600, Gary R Hook wrote:
> On 11/13/2016 03:49 AM, Herbert Xu wrote:
> >On Tue, Nov 01, 2016 at 02:05:05PM -0500, Gary R Hook wrote:
> >>The exponent size in the ccp_op structure is in bits. A v5
> >>CCP requires the exponent size to be in bytes, so convert
> >>the size from bits to bytes when populating the descriptor.
> >>
> >>The current code references the exponent in memory, but
> >>these fields have not been set since the exponent is
> >>actually store in the LSB. Populate the descriptor with
> >>the LSB location (address).
> >>
> >>Signed-off-by: Gary R Hook <gary.hook@amd.com>
> >
> >Patch applied. Thanks.
> >
>
> Thanks, Herbert.
>
> Is there a possibility of getting this pushed to 4.9, being
> it's a bug fix?
I thought ccp doesn't support RSA yet or is there another entry
path into this code?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Herbert Xu @ 2016-11-16 8:59 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <20161116085742.GA29644@gondor.apana.org.au>
On Wed, Nov 16, 2016 at 04:57:42PM +0800, Herbert Xu wrote:
> On Tue, Nov 15, 2016 at 08:06:47PM +0100, Stephan Mueller wrote:
> >
> > Shall the fix be rolled into the patch together with the fix for the tag value
> > as well as the crash fix? Or can we have a stand-alone patch fixing this.
>
> I think these are two separate issues and we don't need to fix them
> all in one go.
>
> > Btw., how do you suggest that should be fixed? I would assume that this needs
> > to be fixed on a per-implementation basis. I tested authenc and it copies the
> > buffers over. gcm_base(ctr-aes-aesni,ghash-clmulni), rfc4106-gcm-aesni or
> > ccm_base(ctr-aes-aesni,aes-aesni) do not copy the AD over.
>
> We should fix as much as we can and then add a testmgr test to find
> the rest.
Alternatively we can add the copying code to algif_aead when src !=
dst. I think that's probably the easier fix.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Herbert Xu @ 2016-11-16 8:57 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <4916573.RdN3EB8qT2@positron.chronox.de>
On Tue, Nov 15, 2016 at 08:06:47PM +0100, Stephan Mueller wrote:
>
> Shall the fix be rolled into the patch together with the fix for the tag value
> as well as the crash fix? Or can we have a stand-alone patch fixing this.
I think these are two separate issues and we don't need to fix them
all in one go.
> Btw., how do you suggest that should be fixed? I would assume that this needs
> to be fixed on a per-implementation basis. I tested authenc and it copies the
> buffers over. gcm_base(ctr-aes-aesni,ghash-clmulni), rfc4106-gcm-aesni or
> ccm_base(ctr-aes-aesni,aes-aesni) do not copy the AD over.
We should fix as much as we can and then add a testmgr test to find
the rest.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix handling of RSA exponent on a v5 device
From: Gary R Hook @ 2016-11-15 21:41 UTC (permalink / raw)
To: Herbert Xu, Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161113094921.GB7399@gondor.apana.org.au>
On 11/13/2016 03:49 AM, Herbert Xu wrote:
> On Tue, Nov 01, 2016 at 02:05:05PM -0500, Gary R Hook wrote:
>> The exponent size in the ccp_op structure is in bits. A v5
>> CCP requires the exponent size to be in bytes, so convert
>> the size from bits to bytes when populating the descriptor.
>>
>> The current code references the exponent in memory, but
>> these fields have not been set since the exponent is
>> actually store in the LSB. Populate the descriptor with
>> the LSB location (address).
>>
>> Signed-off-by: Gary R Hook <gary.hook@amd.com>
>
> Patch applied. Thanks.
>
Thanks, Herbert.
Is there a possibility of getting this pushed to 4.9, being
it's a bug fix?
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: [PATCH V2 6/9] crypto: ccp - Add support for RSA on the CCP
From: Gary R Hook @ 2016-11-15 21:42 UTC (permalink / raw)
To: Herbert Xu, Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161113093930.GA7299@gondor.apana.org.au>
On 11/13/2016 03:39 AM, Herbert Xu wrote:
> On Fri, Nov 04, 2016 at 11:04:32AM -0500, Gary R Hook wrote:
>>
>> + ctx->u.rsa.pkey.e = mpi_read_raw_data(raw_key.e, raw_key.e_sz);
>> + if (!ctx->u.rsa.pkey.e)
>> + goto e_ret;
>> + ctx->u.rsa.e_buf = mpi_get_buffer(ctx->u.rsa.pkey.e,
>> + &ctx->u.rsa.e_len, NULL);
>
> You're converting a raw integer into an MPI and then back again.
> Why?
>
> In general drivers shouldn't touch the MPI stuff at all since the
> hardware generally deals with raw integers.
D'oh! Yes, I see now what I missed before.
I will send out another patch set.
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: [RFC][PATCH 0/6] crypto: Adding Hash-Encrypt-Hash(HEH)
From: Alex Cope @ 2016-11-15 20:40 UTC (permalink / raw)
To: linux-crypto; +Cc: Michael Halcrow, Ed Knapp, Alex Cope
I accidentally had an off-by-one in this patch set. There is no patch
7/7. I've edited this subject but don't plan to resend the rest of the
patches to fix the subject lines.
To clarify, this patchset is on top of "crypto: skcipher - skcipher
algorithm conversion part 3" that Herbert currently has out for
review.
Cheers,
-Alex
On Mon, Nov 14, 2016 at 1:01 PM, Alex Cope <alexcope@google.com> wrote:
> This patchset implements HEH, which is currently specified by the
> following Internet Draft:
>
> https://tools.ietf.org/html/draft-cope-heh-00
>
> This patchset is a request for comments, and should not be merged at
> this time. We would like to wait for further comments on the Internet
> Draft before merging this patchset.
>
> Thanks
^ permalink raw reply
* Re: [PATCH 2/3] crypto: AF_ALG - disregard AAD buffer space for output
From: Stephan Mueller @ 2016-11-15 19:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: mathew.j.martineau, linux-crypto
In-Reply-To: <20161112021302.GA32425@gondor.apana.org.au>
Am Samstag, 12. November 2016, 10:13:02 CET schrieb Herbert Xu:
Hi Herbert,
> On Sat, Nov 12, 2016 at 03:03:36AM +0100, Stephan Mueller wrote:
> > When you have separate buffers, the kernel does not seem to copy the AD
> > over to the target buffer.
>
> OK we should definitely fix that.
Shall the fix be rolled into the patch together with the fix for the tag value
as well as the crash fix? Or can we have a stand-alone patch fixing this.
Btw., how do you suggest that should be fixed? I would assume that this needs
to be fixed on a per-implementation basis. I tested authenc and it copies the
buffers over. gcm_base(ctr-aes-aesni,ghash-clmulni), rfc4106-gcm-aesni or
ccm_base(ctr-aes-aesni,aes-aesni) do not copy the AD over.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] fscrypto: don't use on-stack buffer for key derivation
From: Eric Biggers @ 2016-11-15 18:53 UTC (permalink / raw)
To: Theodore Ts'o
Cc: linux-fsdevel, linux-ext4, linux-f2fs-devel, linux-crypto,
jaegeuk, richard, luto
In-Reply-To: <20161115164704.5tzvm2g2x2fyetyu@thunk.org>
On Tue, Nov 15, 2016 at 11:47:04AM -0500, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote:
> > With the new (in 4.9) option to use a virtually-mapped stack
> > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> > the scatterlist crypto API because they may not be directly mappable to
> > struct page. get_crypt_info() was using a stack buffer to hold the
> > output from the encryption operation used to derive the per-file key.
> > Fix it by using a heap buffer.
> >
> > This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
> > because this allowed the BUG in sg_set_buf() to be triggered.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> This commit is on the fscrypt and dev branches on ext4.git.
>
> - Ted
Hi Ted,
Would it make any sense to send these two patches to Linus for v4.9-rc6, given
that they fix bugs introduced in 4.9 with the virtually-mapped stack feature?
Or would you prefer to wait and have them go to 4.9 via stable?
Note that CONFIG_VMAP_STACK defaults to y on x86_64.
Thanks,
Eric
^ permalink raw reply
* [RFC PATCH] powerpc: crypto/vmx: clean up generated files
From: Naveen N. Rao @ 2016-11-15 17:05 UTC (permalink / raw)
To: Leonidas S. Barbosa, Herbert Xu
Cc: Paulo Flabiano Smorigo, linux-crypto, linuxppc-dev,
Michael Ellerman
..as stray .S files result in build errors, especially when using
cross-compilers.
More specifically, the generated .S files are endian-specific and will break
subsequent builds targeting the other endian architecture.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
drivers/crypto/vmx/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index de6e241..31b25cb 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -16,4 +16,4 @@ $(src)/aesp8-ppc.S: $(src)/aesp8-ppc.pl
$(src)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl
$(call cmd,perl)
-.PRECIOUS: $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S
+clean-files := aesp8-ppc.S ghashp8-ppc.S
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] crypto: sha*-mb Fix total_len for correct hash when larger than 512MB
From: Tim Chen @ 2016-11-15 16:50 UTC (permalink / raw)
To: Greg Tucker, herbert, linux-crypto; +Cc: megha.dey, xiaodong.liu
In-Reply-To: <1479165104-24356-1-git-send-email-greg.b.tucker@intel.com>
On Mon, 2016-11-14 at 16:11 -0700, Greg Tucker wrote:
> Current multi-buffer hash implementations have a restriction on the total
> length of a hash job to 512MB. Hashing larger buffers will result in an
> incorrect hash. This extends the limit to 2^62 - 1.
>
> Signed-off-by: Greg Tucker <greg.b.tucker@intel.com>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
> arch/x86/crypto/sha1-mb/sha1_mb.c | 2 +-
> arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 2 +-
> arch/x86/crypto/sha256-mb/sha256_mb.c | 2 +-
> arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 2 +-
> arch/x86/crypto/sha512-mb/sha512_mb.c | 2 +-
> arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/crypto/sha1-mb/sha1_mb.c b/arch/x86/crypto/sha1-mb/sha1_mb.c
> index 9e5b671..acf9fdf 100644
> --- a/arch/x86/crypto/sha1-mb/sha1_mb.c
> +++ b/arch/x86/crypto/sha1-mb/sha1_mb.c
> @@ -114,7 +114,7 @@ static inline void sha1_init_digest(uint32_t *digest)
> }
>
> static inline uint32_t sha1_pad(uint8_t padblock[SHA1_BLOCK_SIZE * 2],
> - uint32_t total_len)
> + uint64_t total_len)
> {
> uint32_t i = total_len & (SHA1_BLOCK_SIZE - 1);
>
> diff --git a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
> index 98a35bc..13590cc 100644
> --- a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
> +++ b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
> @@ -125,7 +125,7 @@ struct sha1_hash_ctx {
> /* error flag */
> int error;
>
> - uint32_t total_length;
> + uint64_t total_length;
> const void *incoming_buffer;
> uint32_t incoming_buffer_length;
> uint8_t partial_block_buffer[SHA1_BLOCK_SIZE * 2];
> diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c b/arch/x86/crypto/sha256-mb/sha256_mb.c
> index 6f97fb3..7926a22 100644
> --- a/arch/x86/crypto/sha256-mb/sha256_mb.c
> +++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
> @@ -115,7 +115,7 @@ inline void sha256_init_digest(uint32_t *digest)
> }
>
> inline uint32_t sha256_pad(uint8_t padblock[SHA256_BLOCK_SIZE * 2],
> - uint32_t total_len)
> + uint64_t total_len)
> {
> uint32_t i = total_len & (SHA256_BLOCK_SIZE - 1);
>
> diff --git a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
> index edd252b..aabb303 100644
> --- a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
> +++ b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
> @@ -125,7 +125,7 @@ struct sha256_hash_ctx {
> /* error flag */
> int error;
>
> - uint32_t total_length;
> + uint64_t total_length;
> const void *incoming_buffer;
> uint32_t incoming_buffer_length;
> uint8_t partial_block_buffer[SHA256_BLOCK_SIZE * 2];
> diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c b/arch/x86/crypto/sha512-mb/sha512_mb.c
> index d210174..9c1bb6d 100644
> --- a/arch/x86/crypto/sha512-mb/sha512_mb.c
> +++ b/arch/x86/crypto/sha512-mb/sha512_mb.c
> @@ -117,7 +117,7 @@ inline void sha512_init_digest(uint64_t *digest)
> }
>
> inline uint32_t sha512_pad(uint8_t padblock[SHA512_BLOCK_SIZE * 2],
> - uint32_t total_len)
> + uint64_t total_len)
> {
> uint32_t i = total_len & (SHA512_BLOCK_SIZE - 1);
>
> diff --git a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
> index 9d4b2c8..e4653f5 100644
> --- a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
> +++ b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
> @@ -119,7 +119,7 @@ struct sha512_hash_ctx {
> /* error flag */
> int error;
>
> - uint32_t total_length;
> + uint64_t total_length;
> const void *incoming_buffer;
> uint32_t incoming_buffer_length;
> uint8_t partial_block_buffer[SHA512_BLOCK_SIZE * 2];
^ permalink raw reply
* Re: [PATCH 2/2] fscrypto: don't use on-stack buffer for key derivation
From: Theodore Ts'o @ 2016-11-15 16:47 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fsdevel, linux-ext4, linux-f2fs-devel, linux-crypto,
jaegeuk, richard, luto
In-Reply-To: <1478210582-86338-2-git-send-email-ebiggers@google.com>
On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote:
> With the new (in 4.9) option to use a virtually-mapped stack
> (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> the scatterlist crypto API because they may not be directly mappable to
> struct page. get_crypt_info() was using a stack buffer to hold the
> output from the encryption operation used to derive the per-file key.
> Fix it by using a heap buffer.
>
> This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
> because this allowed the BUG in sg_set_buf() to be triggered.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
This commit is on the fscrypt and dev branches on ext4.git.
- Ted
^ permalink raw reply
* Re: [PATCH 1/2] fscrypto: don't use on-stack buffer for filename encryption
From: Theodore Ts'o @ 2016-11-15 16:46 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fsdevel, linux-ext4, linux-f2fs-devel, linux-crypto,
jaegeuk, richard, luto
In-Reply-To: <1478210582-86338-1-git-send-email-ebiggers@google.com>
On Thu, Nov 03, 2016 at 03:03:01PM -0700, Eric Biggers wrote:
> With the new (in 4.9) option to use a virtually-mapped stack
> (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> the scatterlist crypto API because they may not be directly mappable to
> struct page. For short filenames, fname_encrypt() was encrypting a
> stack buffer holding the padded filename. Fix it by encrypting the
> filename in-place in the output buffer, thereby making the temporary
> buffer unnecessary.
>
> This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
> because this allowed the BUG in sg_set_buf() to be triggered.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
This commit is on the fscrypt and dev branches on ext4.git.
- Ted
^ permalink raw reply
* Re: [v2 PATCH 7/16] crypto: simd - Add simd skcipher helper
From: Herbert Xu @ 2016-11-15 14:55 UTC (permalink / raw)
To: Eric Biggers; +Cc: Linux Crypto Mailing List
In-Reply-To: <20161114022740.GD4778@google.com>
On Sun, Nov 13, 2016 at 06:27:40PM -0800, Eric Biggers wrote:
> On Sun, Nov 13, 2016 at 07:45:38PM +0800, Herbert Xu wrote:
> > This patch adds the simd skcipher helper which is meant to be
> > a replacement for ablk helper. It replaces the underlying blkcipher
> > interface with skcipher, and also presents the top-level algorithm
> > as an skcipher.
>
> I assume this means it's planned for all users of ablk_helper to be migrated to
> crypto_simd, and ablk_helper will be removed?
Yes that's the idea.
> > + salg = kzalloc(sizeof(*alg), GFP_KERNEL);
> > + if (!salg) {
> > + salg = ERR_PTR(-ENOMEM);
> > + goto out_put_tfm;
> > + }
>
> Shouldn't this be 'sizeof(*salg)'?
Good catch. I'll fix this.
> > + tfm = crypto_alloc_skcipher(basename, CRYPTO_ALG_INTERNAL,
> > + CRYPTO_ALG_INTERNAL | CRYPTO_ALG_ASYNC);
> > + if (IS_ERR(tfm))
> > + return ERR_CAST(tfm);
> > +
> > + ialg = crypto_skcipher_alg(tfm);
>
> It seems this really just needs an algorithm and not a transform. Perhaps it
> should be calling crypto_find_alg() directly?
crypto_find_alg is an internal API function that should not be used
unless you're implementing a crypto_type. Ugh I see that it is being
abused already. I'll get this fixed.
As a rule internal.h should only be used by API implementors, not
algorithm implementors.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [v2 PATCH 4/16] crypto: xts - Convert to skcipher
From: Herbert Xu @ 2016-11-15 14:41 UTC (permalink / raw)
To: Eric Biggers; +Cc: Linux Crypto Mailing List
In-Reply-To: <20161114021029.GC4778@google.com>
On Sun, Nov 13, 2016 at 06:10:29PM -0800, Eric Biggers wrote:
>
> There's duplicated code for encryption and decryption here. AFAICS, the only
> difference between XTS encryption and decryption is whether the block cipher is
> used in encryption or decryption mode for the ECB step. So I suggest storing a
> function pointer in 'struct rctx' to either crypto_skcipher_encrypt or
> crypto_skcipher_decrypt, then calling through it for the ECB step. Then this
> code can be shared. In other words I'd like the top-level functions to look
> like this:
I'm all for getting rid of duplicate code. However, I'd also
prefer to do it without using indirect function calls in this
case.
> I'm also wondering about the line which does
> 'subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;'.
> Is the real intent of that to clear the CRYPTO_TFM_REQ_MAY_SLEEP flag because
> the completion callback may be called in an atomic context, and if so shouldn't
> it just clear that flag only, rather than all flags except
> CRYPTO_TFM_REQ_MAY_BACKLOG?
The intent here is that this is the only flag that we want to
pass along. Of course in the absence of any other flags it's a
moot point.
> > + if (req->cryptlen > XTS_BUFFER_SIZE) {
> > + subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
> > + rctx->ext = kmalloc(subreq->cryptlen, gfp);
> > + }
>
> There's no check for failure to allocate the 'rctx->ext' memory.
The code is supposed to handle a NULL rctx->ext gracefully. Did
you find a spot where it is used without checking?
> > + if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME,
> > + "xts(%s)", ctx->name) >= CRYPTO_MAX_ALG_NAME)
> > + return -ENAMETOOLONG;
> > + } else
> > + goto err_drop_spawn;
>
> There should be a line which sets 'err = -EINVAL' before here.
Indeed. Fixed here as well as in lrw.
> > +static int init_crypt(struct skcipher_request *req, crypto_completion_t done)
> > {
> > - struct priv *ctx = crypto_blkcipher_ctx(desc->tfm);
> > - struct blkcipher_walk w;
> > + struct priv *ctx = crypto_skcipher_ctx(crypto_skcipher_reqtfm(req));
> > + struct rctx *rctx = skcipher_request_ctx(req);
> > + struct skcipher_request *subreq;
> > + be128 *buf;
> ...
> > + /* calculate first value of T */
> > + buf = rctx->ext ?: rctx->buf;
> > + crypto_cipher_encrypt_one(ctx->tweak, (u8 *)&rctx->t, req->iv);
> > +
> > + return 0;
>
> The 'buf' variable is assigned to but never used.
OK, deleted.
> > int xts_crypt(struct blkcipher_desc *desc, struct scatterlist *sdst,
> > @@ -233,112 +416,167 @@ int xts_crypt(struct blkcipher_desc *desc, struct scatterlist *sdst,
> > }
> > EXPORT_SYMBOL_GPL(xts_crypt);
>
> xts_crypt() is still here. Is there a plan for its removal, since now the
> generic XTS algorithm can use an accelerated ECB algorithm?
It will be removed once all the arch code that uses it are converted.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [v2 PATCH 1/16] crypto: skcipher - Add skcipher walk interface
From: Herbert Xu @ 2016-11-15 13:58 UTC (permalink / raw)
To: Eric Biggers; +Cc: Linux Crypto Mailing List
In-Reply-To: <20161114013548.GA4778@google.com>
Hi Eric:
On Sun, Nov 13, 2016 at 05:35:48PM -0800, Eric Biggers wrote:
> Hi Herbert,
>
> On Sun, Nov 13, 2016 at 07:45:32PM +0800, Herbert Xu wrote:
> > +int skcipher_walk_done(struct skcipher_walk *walk, int err)
> > +{
> > + unsigned int nbytes = 0;
> > + unsigned int n = 0;
> > +
> > + if (likely(err >= 0)) {
> > + n = walk->nbytes - err;
> > + nbytes = walk->total - n;
> > + }
> > +
> > + if (likely(!(walk->flags & (SKCIPHER_WALK_PHYS |
> > + SKCIPHER_WALK_SLOW |
> > + SKCIPHER_WALK_COPY |
> > + SKCIPHER_WALK_DIFF)))) {
> > +unmap_src:
> > + skcipher_unmap_src(walk);
>
> Isn't it wrong to unmap the buffers when err < 0? They won't have been mapped
> yet, e.g. if the 'skcipher_walk_done(walk, -EINVAL)' case is hit.
Indeed. The unmapping code needs to be inside the first if clause.
I'll rearrange it.
> > + /* Short-circuit for the common/fast path. */
> > + if (!(((unsigned long)walk->iv ^ (unsigned long)walk->oiv) |
> > + ((unsigned long)walk->buffer ^ (unsigned long)walk->page) |
> > + (unsigned long)walk->page))
> > + goto out;
>
> This is really saying that the IV wasn't copied and that walk->buffer and
> walk->page are both NULL. But if walk->buffer is NULL then the IV wasn't
> copied. So this can be simplified to:
>
> if (!((unsigned long)walk->buffer | (unsigned long)walk->page))
> goto out;
Nice, I'll use this.
> > +int skcipher_walk_next(struct skcipher_walk *walk)
> > +{
>
> Shouldn't this be static? There's even a static declaration earlier in the
> file.
Yes, static added.
> > +static int skcipher_next_slow(struct skcipher_walk *walk)
> > +{
> > + bool phys = walk->flags & SKCIPHER_WALK_PHYS;
> > + unsigned alignmask = walk->alignmask;
> > + unsigned bsize = walk->chunksize;
> ...
> > + walk->nbytes = bsize;
>
> skcipher_next_slow() is always setting up 'chunksize' bytes to be processed.
> Isn't this wrong in the 'blocksize < chunksize' case because fewer than
> 'chunksize' bytes may need to be processed?
Good catch. This is supposed to be the bsize from the caller
which is capped by walk->total.
> > +static inline void *skcipher_map(struct scatter_walk *walk)
> > +{
> > + struct page *page = scatterwalk_page(walk);
> > +
> > + return (PageHighMem(page) ? kmap_atomic(page) : page_address(page)) +
> > + offset_in_page(walk->offset);
> > +}
>
> Is the PageHighMem() optimization really worthwhile? It will skip kmap_atomic()
> and hence preempt_disable() for non-highmem pages, so it may make it harder to
> find bugs where users are sleeping when they shouldn't be. It also seems
> inconsistent that skcipher_map() will do this optimization but scatterwalk_map()
> won't.
It did make a big difference on my machine. Because users such
as lrw will call the walker a lot more often after the conversion
to skcipher this is now worthwhile as an optimisation. With the
old code the blkcipher walk was not called as often.
> > + if (!walk->page) {
> > + gfp_t gfp = skcipher_walk_gfp(walk);
> > +
> > + walk->page = (void *)__get_free_page(gfp);
> > + if (!walk->page)
> > + goto slow_path;
> > + }
> > +
> > + walk->nbytes = min_t(unsigned, n,
> > + PAGE_SIZE - offset_in_page(walk->page));
>
> walk->page will be page-aligned, so there's no need for offset_in_page(). Also,
> 'n' has already been clamped to at most one page. So AFAICS this can simply be
> 'walk->nbytes = n;'.
This is valid for the sync walk, but not for the async case. In
the async case, we will reuse the page if the previous copy did
not completely consume it.
> > +int skcipher_walk_done(struct skcipher_walk *walk, int err);
> ...
> > +void skcipher_walk_complete(struct skcipher_walk *walk, int err);
>
> The naming is confusing: "done" vs. "complete". They can easily be mixed up.
> Would it make more sense to have something with "async" in the name for the
> second one, like skcipher_walk_async_done()?
I see your point. But I think async_done would also be confusing
because the async case needs to call both skcipher_walk_done and
skcipher_walk_async_done.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: sha*-mb Fix total_len for correct hash when larger than 512MB
From: Greg Tucker @ 2016-11-14 23:11 UTC (permalink / raw)
To: herbert, linux-crypto; +Cc: megha.dey, tim.c.chen, xiaodong.liu, Greg Tucker
Current multi-buffer hash implementations have a restriction on the total
length of a hash job to 512MB. Hashing larger buffers will result in an
incorrect hash. This extends the limit to 2^62 - 1.
Signed-off-by: Greg Tucker <greg.b.tucker@intel.com>
---
arch/x86/crypto/sha1-mb/sha1_mb.c | 2 +-
arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 2 +-
arch/x86/crypto/sha256-mb/sha256_mb.c | 2 +-
arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 2 +-
arch/x86/crypto/sha512-mb/sha512_mb.c | 2 +-
arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/crypto/sha1-mb/sha1_mb.c b/arch/x86/crypto/sha1-mb/sha1_mb.c
index 9e5b671..acf9fdf 100644
--- a/arch/x86/crypto/sha1-mb/sha1_mb.c
+++ b/arch/x86/crypto/sha1-mb/sha1_mb.c
@@ -114,7 +114,7 @@ static inline void sha1_init_digest(uint32_t *digest)
}
static inline uint32_t sha1_pad(uint8_t padblock[SHA1_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA1_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
index 98a35bc..13590cc 100644
--- a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
+++ b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
@@ -125,7 +125,7 @@ struct sha1_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA1_BLOCK_SIZE * 2];
diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c b/arch/x86/crypto/sha256-mb/sha256_mb.c
index 6f97fb3..7926a22 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb.c
+++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
@@ -115,7 +115,7 @@ inline void sha256_init_digest(uint32_t *digest)
}
inline uint32_t sha256_pad(uint8_t padblock[SHA256_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA256_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
index edd252b..aabb303 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
+++ b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
@@ -125,7 +125,7 @@ struct sha256_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA256_BLOCK_SIZE * 2];
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c b/arch/x86/crypto/sha512-mb/sha512_mb.c
index d210174..9c1bb6d 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb.c
@@ -117,7 +117,7 @@ inline void sha512_init_digest(uint64_t *digest)
}
inline uint32_t sha512_pad(uint8_t padblock[SHA512_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA512_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
index 9d4b2c8..e4653f5 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
+++ b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
@@ -119,7 +119,7 @@ struct sha512_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA512_BLOCK_SIZE * 2];
--
2.5.5
^ permalink raw reply related
* [RFC][PATCH 6/7] crypto: testmgr - Add test vectors for HEH
From: Alex Cope @ 2016-11-14 21:01 UTC (permalink / raw)
To: linux-crypto; +Cc: mhalcrow, edknapp, Alex Cope, Eric Biggers
In-Reply-To: <1479157277-10251-1-git-send-email-alexcope@google.com>
Adding test vectors from
https://tools.ietf.org/html/draft-cope-heh-00
Signed-off-by: Alex Cope <alexcope@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/testmgr.c | 15 ++++
crypto/testmgr.h | 226 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 241 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ded50b6..bab027b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3481,6 +3481,21 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "heh(aes)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = {
+ .vecs = aes_heh_enc_tv_template,
+ .count = AES_HEH_ENC_TEST_VECTORS
+ },
+ .dec = {
+ .vecs = aes_heh_dec_tv_template,
+ .count = AES_HEH_DEC_TEST_VECTORS
+ }
+ }
+ }
+ }, {
.alg = "hmac(crc32)",
.test = alg_test_hash,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index e64a4ef..b2daad3 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -15172,6 +15172,8 @@ static struct cipher_testvec cast6_xts_dec_tv_template[] = {
#define AES_DEC_TEST_VECTORS 4
#define AES_CBC_ENC_TEST_VECTORS 5
#define AES_CBC_DEC_TEST_VECTORS 5
+#define AES_HEH_ENC_TEST_VECTORS 4
+#define AES_HEH_DEC_TEST_VECTORS 4
#define HMAC_MD5_ECB_CIPHER_NULL_ENC_TEST_VECTORS 2
#define HMAC_MD5_ECB_CIPHER_NULL_DEC_TEST_VECTORS 2
#define HMAC_SHA1_ECB_CIPHER_NULL_ENC_TEST_VEC 2
@@ -15544,6 +15546,230 @@ static struct cipher_testvec aes_dec_tv_template[] = {
},
};
+static struct cipher_testvec aes_heh_enc_tv_template[] = {
+ {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .input = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .ilen = 16,
+ .result = "\x61\x76\x38\xa5\x12\x0b\x6d\x89"
+ "\x92\x68\x30\x7e\x0d\x6e\x81\xe3",
+ .rlen = 16,
+ .also_non_np = 1,
+ .np = 2,
+ .tap = { 8, 8 },
+ }, {
+ .key = "\x68\xf8\x27\x87\xdc\x30\x33\xfd"
+ "\x65\x5b\x8e\x51\x2e\x02\xff\x9d"
+ "\x21\x28\x1e\x64\xcd\x9c\x33\x88"
+ "\xf6\x2c\x43\x8f\xf5\x6f\xf5\x8f"
+ "\xa8\xda\x24\x9b\x5e\xfa\x13\xc2"
+ "\xc1\x94\xbf\x32\xba\x38\xa3\x77",
+ .klen = 48,
+ .iv = "\x4d\x47\x61\x37\x2b\x47\x86\xf0"
+ "\xd6\x47\xb5\xc2\xe8\xcf\x85\x27",
+ .input = "\xb8\xee\x29\xe4\xa5\xd1\xe7\x55"
+ "\xd0\xfd\xe7\x22\x63\x76\x36\xe2"
+ "\xf8\x0c\xf8\xfe\x65\x76\xe7\xca"
+ "\xc1\x42\xf5\xca\x5a\xa8\xac\x2a",
+ .ilen = 32,
+ .result = "\x1f\x4c\x6a\x1e\x1d\x20\x0d\x99"
+ "\xdf\xbb\x13\xd8\x35\xdc\x1d\xbe"
+ "\xed\x50\x0a\x9f\xfd\xd6\x94\x85"
+ "\xd0\x8b\xf7\xb4\x49\x7f\x70\x6d",
+ .rlen = 32,
+ .also_non_np = 1,
+ .np = 3,
+ .tap = { 16, 13, 3 },
+ }, {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00",
+ .ilen = 63,
+ .result = "\xfb\x30\x90\x47\xc5\x4e\xcc\xfd"
+ "\xc4\x90\xa2\x9f\x7c\x03\x63\xc3"
+ "\xcb\xaf\x2e\xee\x62\x18\xeb\x20"
+ "\x62\x97\xe4\x9b\xf2\x8b\xf3\x3f"
+ "\x76\x3b\xaa\xab\xf0\x19\x54\xdb"
+ "\xb4\xaf\x2e\xd9\xa7\xe0\x92\x04"
+ "\x5a\xe4\x81\xfc\x58\xf2\xda\xbf"
+ "\x5d\xc9\xb1\x47\xd5\x08\xb1",
+ .rlen = 63,
+ .also_non_np = 1,
+ .np = 8,
+ .tap = { 20, 20, 10, 8, 2, 1, 1, 1 },
+ }, {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x01"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00",
+ .ilen = 63,
+ .result = "\x9c\xdf\xa5\x50\x83\xe0\xa3\xb5"
+ "\x0d\x35\x83\x34\x6e\x6e\x40\xd6"
+ "\x0f\x81\xc8\x1a\x9c\x40\x81\xfb"
+ "\xb3\x6e\xb4\xbf\xfc\xca\xc9\x50"
+ "\xcd\x33\xfd\xb3\x43\x11\xe6\x32"
+ "\x02\x3d\x3e\xc6\x49\x6e\xcf\x58"
+ "\x3e\x14\x15\x6d\x39\x2a\x58\x99"
+ "\x83\xaf\xdd\x22\x3e\x7f\x6c",
+ .rlen = 63,
+ .also_non_np = 1,
+ .np = 8,
+ .tap = { 20, 20, 10, 8, 2, 1, 1, 1 },
+ }
+};
+
+static struct cipher_testvec aes_heh_dec_tv_template[] = {
+ {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .input = "\x61\x76\x38\xa5\x12\x0b\x6d\x89"
+ "\x92\x68\x30\x7e\x0d\x6e\x81\xe3",
+ .ilen = 16,
+ .result = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .rlen = 16,
+ .also_non_np = 1,
+ .np = 2,
+ .tap = { 8, 8 },
+ }, {
+ .key = "\x68\xf8\x27\x87\xdc\x30\x33\xfd"
+ "\x65\x5b\x8e\x51\x2e\x02\xff\x9d"
+ "\x21\x28\x1e\x64\xcd\x9c\x33\x88"
+ "\xf6\x2c\x43\x8f\xf5\x6f\xf5\x8f"
+ "\xa8\xda\x24\x9b\x5e\xfa\x13\xc2"
+ "\xc1\x94\xbf\x32\xba\x38\xa3\x77",
+ .klen = 48,
+ .iv = "\x4d\x47\x61\x37\x2b\x47\x86\xf0"
+ "\xd6\x47\xb5\xc2\xe8\xcf\x85\x27",
+ .input = "\x1f\x4c\x6a\x1e\x1d\x20\x0d\x99"
+ "\xdf\xbb\x13\xd8\x35\xdc\x1d\xbe"
+ "\xed\x50\x0a\x9f\xfd\xd6\x94\x85"
+ "\xd0\x8b\xf7\xb4\x49\x7f\x70\x6d",
+ .ilen = 32,
+ .result = "\xb8\xee\x29\xe4\xa5\xd1\xe7\x55"
+ "\xd0\xfd\xe7\x22\x63\x76\x36\xe2"
+ "\xf8\x0c\xf8\xfe\x65\x76\xe7\xca"
+ "\xc1\x42\xf5\xca\x5a\xa8\xac\x2a",
+ .rlen = 32,
+ .also_non_np = 1,
+ .np = 3,
+ .tap = { 16, 13, 3 },
+ }, {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .result = "\xfb\x30\x90\x47\xc5\x4e\xcc\xfd"
+ "\xc4\x90\xa2\x9f\x7c\x03\x63\xc3"
+ "\xcb\xaf\x2e\xee\x62\x18\xeb\x20"
+ "\x62\x97\xe4\x9b\xf2\x8b\xf3\x3f"
+ "\x76\x3b\xaa\xab\xf0\x19\x54\xdb"
+ "\xb4\xaf\x2e\xd9\xa7\xe0\x92\x04"
+ "\x5a\xe4\x81\xfc\x58\xf2\xda\xbf"
+ "\x5d\xc9\xb1\x47\xd5\x08\xb1",
+ .ilen = 63,
+ .input = "\xfb\x30\x90\x47\xc5\x4e\xcc\xfd"
+ "\xc4\x90\xa2\x9f\x7c\x03\x63\xc3"
+ "\xcb\xaf\x2e\xee\x62\x18\xeb\x20"
+ "\x62\x97\xe4\x9b\xf2\x8b\xf3\x3f"
+ "\x76\x3b\xaa\xab\xf0\x19\x54\xdb"
+ "\xb4\xaf\x2e\xd9\xa7\xe0\x92\x04"
+ "\x5a\xe4\x81\xfc\x58\xf2\xda\xbf"
+ "\x5d\xc9\xb1\x47\xd5\x08\xb1",
+ .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00",
+ .rlen = 63,
+ .also_non_np = 1,
+ .np = 8,
+ .tap = { 20, 20, 10, 8, 2, 1, 1, 1 },
+ }, {
+ .key = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F"
+ "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F",
+ .klen = 48,
+ .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+ .input = "\x9c\xdf\xa5\x50\x83\xe0\xa3\xb5"
+ "\x0d\x35\x83\x34\x6e\x6e\x40\xd6"
+ "\x0f\x81\xc8\x1a\x9c\x40\x81\xfb"
+ "\xb3\x6e\xb4\xbf\xfc\xca\xc9\x50"
+ "\xcd\x33\xfd\xb3\x43\x11\xe6\x32"
+ "\x02\x3d\x3e\xc6\x49\x6e\xcf\x58"
+ "\x3e\x14\x15\x6d\x39\x2a\x58\x99"
+ "\x83\xaf\xdd\x22\x3e\x7f\x6c",
+ .ilen = 63,
+ .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x01"
+ "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00",
+ .rlen = 63,
+ .also_non_np = 1,
+ .np = 8,
+ .tap = { 20, 20, 10, 8, 2, 1, 1, 1 },
+ }
+};
+
static struct cipher_testvec aes_cbc_enc_tv_template[] = {
{ /* From RFC 3602 */
.key = "\x06\xa9\x21\x40\x36\xb8\xa1\x5b"
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox