Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com

2016-11-16 Thread bee...@gmx.com 
Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber:  
+79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com
--
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] powerpc: crypto/vmx: various build fixes

2016-11-16 Thread Michael Ellerman 
"Naveen N. Rao"  writes:

> 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 
> Signed-off-by: Naveen N. Rao 
> ---
> 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.

Yeah that's fine, thanks.

Crypto patches usually have a subject like:

crypto: vmx - Various build fixes


But maybe Herbert can fix it up for you when he applies this.

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

[REGRESSION] 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")

2016-11-16 Thread Laura Abbott 
Hi,

Fedora got a bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1395896
of an oops with this program:

#include 
#include 
#include 

int main(int argc, char *argv[]) {
static const union {
struct sockaddr sa;
struct sockaddr_alg alg;
} sa = {
.alg.salg_family = AF_ALG,
.alg.salg_type = "hash",
.alg.salg_name = "sha256",
};
char c;
int fd1, fd2;

fd1 = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(fd1, , sizeof(sa));
fd2 = accept(fd1, NULL, 0);
recv(fd2, , sizeof(c), 0);

return 0;
}


[   10.802304] BUG: unable to handle kernel NULL pointer dereference at 
0008
[   10.803970] IP: [] shash_ahash_digest+0x1e/0x100
[   10.805046] PGD eb37067 PUD 12425067 PMD 0 
[   10.806019] Oops:  [#1] SMP
[   10.806702] Modules linked in:
[   10.807421] CPU: 0 PID: 1098 Comm: a.out Not tainted 4.8.0-rc1+ #29
[   10.808444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.1-1.fc24 04/01/2014
[   10.809839] task: 880010a92400 task.stack: 880012458000
[   10.810653] RIP: 0010:[]  [] 
shash_ahash_digest+0x1e/0x100
[   10.811979] RSP: 0018:88001245bd48  EFLAGS: 00010246
[   10.812730] RAX: 1000 RBX: 88001249b390 RCX: 
[   10.814419] RDX:  RSI: 88001249b390 RDI: 88001249b340
[   10.815303] RBP: 88001245bd68 R08: 88000eb54fa0 R09: 
[   10.816126] R10: 88000eb547d0 R11: 0001 R12: 812f7520
[   10.816946] R13: 88001249b340 R14: 88001245be38 R15: 
[   10.818098] FS:  7f1849f3a700() GS:88001180() 
knlGS:
[   10.819644] CS:  0010 DS:  ES:  CR0: 80050033
[   10.820370] CR2: 0008 CR3: 0eb36000 CR4: 06f0
[   10.821198] Stack:
[   10.821641]  88001249b340 812f7520 880012498c18 
88001245be38
[   10.822905]  88001245bd78 812f753f 88001245bda0 
812f6aa4
[   10.824168]  88001249b060 88001249b060 0001 
88001245bdb0
[   10.825434] Call Trace:
[   10.825910]  [] ? shash_ahash_digest+0x100/0x100
[   10.826663]  [] shash_async_digest+0x1f/0x30
[   10.827389]  [] crypto_ahash_op+0x24/0x60
[   10.828097]  [] crypto_ahash_digest+0x11/0x20
[   10.828835]  [] hash_recvmsg+0x1a4/0x1c0
[   10.829539]  [] sock_recvmsg+0x38/0x40
[   10.830232]  [] SYSC_recvfrom+0xcb/0x130
[   10.830937]  [] ? sock_map_fd+0x3f/0x60
[   10.831635]  [] SyS_recvfrom+0x9/0x10
[   10.832317]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
[   10.833091] Code: 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 b8 00 10 00 00 
48 89 e5 41 56 41 55 41 54 53 49 89 fd 48 8b 4f 38 41 8b 55 30 48 89 f3 <8b> 79 
08 29 f8 39 41 0c 0f 46 41 0c 39 c2 73 74 48 8b 31 48 83 
[   10.838754] RIP  [] shash_ahash_digest+0x1e/0x100
[   10.839560]  RSP 
[   10.840112] CR2: 0008
[   10.840674] ---[ end trace 4314dcc948f7acad ]---
[   10.841320] Kernel panic - not syncing: Fatal exception
[   10.842106] Kernel Offset: disabled

It looks like hash_recvmsg sets the sg to NULL with 

ahash_request_set_crypt(>req, NULL, ctx->result, 0);

which then blows up when crypto_ahash_digest -> hash_ahash_digest
tries to access it. 

Thanks,
Laura
--
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

BUG: algif_hash crash with extra recv() in 4.9-rc5

2016-11-16 Thread Mat Martineau 


Herbert -

Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL 
dereference crash in algif_hash when recv() is called twice like this:


send(sk, data, len, MSG_MORE);
recv(sk, hash1, len, 0);
recv(sk, hash2, len, 0);

In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the 
second recv triggers this:


[   53.041287] BUG: unable to handle kernel NULL pointer dereference at 
0010
[   53.042048] IP: [] shash_ahash_digest+0x23/0x130

(shash_ahash_digest+0x23 corresponds to the second line of the function, 
which accesses sg->offset)


[   53.042572] PGD 131f74067 [   53.042796] PUD 13140f067
PMD 0 [   53.043093] 
[   53.043236] Oops:  [#1] SMP

[   53.043511] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc 
ip6table_raw ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 
nf_nat_ipv6 ip6table_mangle iptable_raw iptable_security iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle 
ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic 
snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hda_core 
ghash_clmulni_intel snd_hwdep snd_seq ppdev snd_seq_device snd_pcm joydev 
snd_timer virtio_balloon snd pcspkr acpi_cpufreq tpm_tis parport_pc parport 
tpm_tis_core tpm i2c_piix4 soundcore qemu_fw_cfg nfsd auth_rpcgss nfs_acl lockd 
grace sunrpc virtio_net virtio_blk virtio_console qxl drm_kms_helper ttm 
ata_generic crc32c_intel drm virtio_pci serio_raw floppy virtio_ring pata_acpi 
virtio
[   53.050799] CPU: 0 PID: 1069 Comm: test-checksum Not tainted 4.9.0-rc5+ #75
[   53.051393] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.1-1.fc24 04/01/2014
[   53.052131] task: 8d2d7243 task.stack: 95b280fe4000
[   53.052622] RIP: 0010:[]  [] 
shash_ahash_digest+0x23/0x130
[   53.053363] RSP: 0018:95b280fe7d40  EFLAGS: 00010246
[   53.053827] RAX: 1000 RBX: 8d2d71c8bbf8 RCX: 
[   53.054424] RDX:  RSI: 8d2d71c8bbf8 RDI: 8d2d71c8bba8
[   53.055014] RBP: 95b280fe7d60 R08: 001ddb00 R09: 8d2d71f03810
[   53.055603] R10:  R11:  R12: a73fe0c0
[   53.056210] R13: 8d2d71c8bba8 R14: 95b280fe7e30 R15: 
[   53.056822] FS:  7f91f1138700() GS:8d2d7b20() 
knlGS:
[   53.057502] CS:  0010 DS:  ES:  CR0: 80050033
[   53.058004] CR2: 0010 CR3: 00013149e000 CR4: 003406f0
[   53.058616] Stack:
[   53.058796]  8d2d71c8bba8 a73fe0c0 8d2d71c8d000 
95b280fe7e30
[   53.059473]  95b280fe7d70 a73fe0e4 95b280fe7d98 
a73fd4c9
[   53.060153]  8d2d71c8b800 8d2d71c8b800 0010 
95b280fe7da8
[   53.060831] Call Trace:
[   53.061051]  [] ? shash_ahash_digest+0x130/0x130
[   53.061601]  [] shash_async_digest+0x24/0x30
[   53.062119]  [] crypto_ahash_op+0x29/0x70
[   53.062621]  [] crypto_ahash_digest+0x16/0x20
[   53.063149]  [] hash_recvmsg+0x1a9/0x1d0
[   53.063655]  [] sock_recvmsg+0x3d/0x50
[   53.064129]  [] SYSC_recvfrom+0xdd/0x160
[   53.064786]  [] ? task_work_run+0x99/0xc0
[   53.065501]  [] ? trace_hardirqs_on_caller+0xf5/0x1b0
[   53.066313]  [] ? trace_hardirqs_on_thunk+0x1a/0x1c
[   53.067069]  [] SyS_recvfrom+0xe/0x10
[   53.067706]  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
[   53.068476] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 b8 00 10 00 00 48 89 e5 41 56 41 55 41 54 53 49 89 fd 48 8b 4f 38 41 8b 55 30 48 89 f3 <8b> 79 10 29 f8 39 41 14 0f 46 41 14 39 c2 72 3a 48 8b 06 48 89 
[   53.071995] RIP  [] shash_ahash_digest+0x23/0x130

[   53.072800]  RSP 
[   53.073259] CR2: 0010
[   53.073700] ---[ end trace 6249058719c9daea ]---

If I revert 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is no crash.


Regards,

--
Mat Martineau
Intel OTC
--
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: ccp - Fix handling of RSA exponent on a v5 device

2016-11-16 Thread Gary R Hook 

On 11/16/2016 03:01 AM, Herbert Xu wrote:

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 


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?


The kernel crypto layer does not yet support RSA, true. However, we
designed the ccp.ko layer to be available to anyone that wants to use
it. The underlying module currently has differing behavior/results
between the v3 and v5 implementations of the RSA command function.
This patch fixes the borked v5 code.


--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
--
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

crypto: caam warning fix, was: master build: 0 failures 1 warnings (v4.9-rc5-177-g81bcfe5)

2016-11-16 Thread Arnd Bergmann 
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 warnings0 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
--
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] powerpc: crypto/vmx: various build fixes

2016-11-16 Thread Naveen N. Rao 
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 
Signed-off-by: Naveen N. Rao 
---
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

--
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] powerpc: crypto/vmx: clean up generated files

2016-11-16 Thread Naveen N. Rao 
On 2016/11/16 09:02PM, Michael Ellerman wrote:
> "Naveen N. Rao"  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

--
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: add virtio-crypto driver

2016-11-16 Thread Gonglei (Arei) 
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_ECB2
> +#define VIRTIO_CRYPTO_CIPHER_AES_CBC3
> +#define VIRTIO_CRYPTO_CIPHER_AES_CTR4
> +#define VIRTIO_CRYPTO_CIPHER_DES_ECB5
> +#define VIRTIO_CRYPTO_CIPHER_DES_CBC6
> +#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_UEA211
> +#define VIRTIO_CRYPTO_CIPHER_AES_F8 12
> +#define VIRTIO_CRYPTO_CIPHER_AES_XTS13
> +#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_HASH0
> +#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_SHA12
> +#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_3DES25
> +#define VIRTIO_CRYPTO_MAC_CMAC_AES 26
> +#define VIRTIO_CRYPTO_MAC_KASUMI_F927
> +#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_GCM1
> +#define VIRTIO_CRYPTO_AEAD_CCM2
> +#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305

Re: [RFC PATCH] powerpc: crypto/vmx: clean up generated files

2016-11-16 Thread Michael Ellerman 
"Naveen N. Rao"  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
--
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/3] crypto: AF_ALG - disregard AAD buffer space for output

2016-11-16 Thread Herbert Xu 
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 
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/3] crypto: AF_ALG - disregard AAD buffer space for output

2016-11-16 Thread Herbert Xu 
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 
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/3] crypto: AF_ALG - disregard AAD buffer space for output

2016-11-16 Thread Stephan Mueller 
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
--
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: ccp - Fix handling of RSA exponent on a v5 device

2016-11-16 Thread Herbert Xu 
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 
> >
> >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 
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/3] crypto: AF_ALG - disregard AAD buffer space for output

2016-11-16 Thread Herbert Xu 
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 
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/3] crypto: AF_ALG - disregard AAD buffer space for output

2016-11-16 Thread Herbert Xu 
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 
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