Re: [PATCH v15 net-next 00/12] Chelsio Inline TLS

[David Miller]

From: Atul Gupta 
Date: Sat, 31 Mar 2018 21:41:51 +0530

> Series for Chelsio Inline TLS driver (chtls)

Series applied, thank you.

Re: [PATCH v2 net-next 0/6] TLS Rx

[David Miller]

From: Dave Watson 
Date: Thu, 22 Mar 2018 10:09:44 -0700

> TLS tcp socket RX implementation, to match existing TX code.

Looks great Dave.  Applied, and once my build tests finish I'll push
this out to net-next.

In some of the new functions, reverse christmas tree ordering of local
variables was not adhered to.

I know it can be difficult in some situations, but please fix this up in
followon patches.  You can move the assignments down into the function
body to accomodate this, if necessary.

Thanks.

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

[David Miller]

From: Atul Gupta 
Date: Sun, 18 Mar 2018 14:30:30 +

> Hi Dave/Herbert,
> 
> This series is against crypto tree, should I submit two patch series:
> 1. netdev specific changes against net-next tree?
> 2. crypto changes against crypto tree?

Herbert, is it OK for this entire series to go via net-next?

Thanks!

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

[David Miller]

From: Atul Gupta 
Date: Fri, 16 Mar 2018 21:06:22 +0530

> Series for Chelsio Inline TLS driver (chtls)

This series doesn't even come close to applying to the net-next
tree, please respin.

Thank you.

Re: [crypto v8 04/12] chtls: structure and macro definiton

[David Miller]

From: Atul Gupta 
Date: Thu,  1 Mar 2018 11:19:35 +0530

> + __u8   reneg_to_write_rx;
> + __u8   protocol;

You should use "u8" rather than "__u8" except in UAPI headers
which this file is not.

Please audit your entire patch series for this issue.

Thank you.

Re: [Crypto v7 00/12] Chelsio Inline TLS

[David Miller]

If nobody is going to actually review these changes for substance and
give real feedback, I will just keep picking the patch series apart
with coding style nitpicks until somebody does.

You have been warned :-)

Re: [Crypto v6 03/12] tls: support for inline tls

[David Miller]

From: Atul Gupta 
Date: Mon, 19 Feb 2018 12:19:41 +0530

> + struct net_device *netdev = NULL;
> +
> + netdev = dev_get_by_index(sock_net(sk), inet->cork.fl.flowi_oif);

No need for an assignment in the variable declaration here.
You immediately set it to something else unconditionally.

> +static int get_tls_offload_dev(struct sock *sk)
> +{
> + struct net_device *netdev;
> + struct tls_device *dev;
> + int rc = 0;
> +
> + netdev = get_netdev(sk);
> + if (!netdev)
> + return -EINVAL;
> +
> + mutex_lock(_mutex);
> + list_for_each_entry(dev, _list, dev_list) {
> + if (dev->netdev && dev->netdev(dev, netdev)) {
> + rc = -EEXIST;
> + break;
> + }
> + }
> + mutex_unlock(_mutex);
> + dev_put(netdev);
> + return rc;
> +}

This is really a confusing function.

It's name suggests that it "gets" the offload device.  In that case,
if it is found it should return success.  Instead we get an -EEXIST
error in that case.  And it returns 0 if not found.

Better to make this do what it says it does, which would be to return
'0' when the device is found and return -ENODEV when it is not found.

> + tcp_prot.unhash(sk);

Do not force this to the ipv4 TCP instance, use the pointer through
the socket to call the proper unhash method.

> + err = tcp_prot.hash(sk);

Likewise.

Re: [Crypto v4 03/12] support for inline tls

[David Miller]

From: Atul Gupta 
Date: Mon, 12 Feb 2018 17:34:28 +0530

> +static int get_tls_prot(struct sock *sk)
> +{
> + struct tls_context *ctx = tls_get_ctx(sk);
> + struct net_device *netdev;
> + struct tls_device *dev;
> +
> + /* Device bound to specific IP */
> + if (inet_sk(sk)->inet_rcv_saddr) {
> + netdev = find_netdev(sk);
> + if (!netdev)
> + goto out;
> +
> + /* Device supports Inline record processing */
> + if (!(netdev->features & NETIF_F_HW_TLS_INLINE))
> + goto out;
> +
> + mutex_lock(_mutex);
> + list_for_each_entry(dev, _list, dev_list) {
> + if (dev->netdev && dev->netdev(dev, netdev))
> + break;
> + }
> + mutex_unlock(_mutex);
> +
> + ctx->tx_conf = TLS_FULL_HW;
> + if (dev->prot)
> + dev->prot(dev, sk);

What if the same IP address is configured on multiple interfaces?

> + } else { /* src address not known or INADDR_ANY */
> + mutex_lock(_mutex);
> + list_for_each_entry(dev, _list, dev_list) {
> + if (dev->feature && dev->feature(dev)) {
> + ctx->tx_conf = TLS_FULL_HW;
> + break;
> + }
> + }
> + mutex_unlock(_mutex);
> + update_sk_prot(sk, ctx);

And I think this is even more of a stretch.  Just because you find
an inline TLS device on the global list doesn't mean traffic will
necessarily flow through it once the connection is fully established
and therefore be able to provide inline TLS offloading.

Re: [Crypto v4 01/12] tls: tls_device struct to register TLS drivers

[David Miller]

From: Atul Gupta 
Date: Mon, 12 Feb 2018 17:33:48 +0530

> + /* When calling get_netdev, the HW vendor's driver should return the
> +  * net device of device @device at port @port_num or NULL if such
> +  * a net device doesn't exist
> +  */
> + struct net_device *(*netdev)(struct tls_device *device,
> +  struct net_device *netdev);

I do not see a "port_num" parameter or structure member anywhere.

Please update this comment to match reality.

Thank you.

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

[David Miller]

From: Vakul Garg 
Date: Wed, 31 Jan 2018 21:34:37 +0530

> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading
> GCM operation. If they are enabled, crypto_aead_encrypt() return error
> code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a
> completion till the time the response for crypto offload request is
> received.
> 
> Signed-off-by: Vakul Garg 
> ---
> v1-v2:
>  - Used crypto_wait_req() to wait for async operation completion
>  - Passed CRYPTO_TFM_REQ_MAY_BACKLOG to crypto_aead_encrypt

Applied.

Re: [PATCH] sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64

[David Miller]

From: Corentin Labbe 
Date: Tue, 23 Jan 2018 14:33:14 +

> This patch fixes the typo CONFIG_CRYPTO_DES_SPARC64 => 
> CONFIG_CRYPTO_CAMELLIA_SPARC64
> 
> Fixes: 81658ad0d923 ("sparc64: Add CAMELLIA driver making use of the new 
> camellia opcodes.")
> Signed-off-by: Corentin Labbe 

Applied, thank you.

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

[David Miller]

From: "Yang Shi" 
Date: Fri, 05 Jan 2018 06:46:48 +0800

> Any more comment on this change?

These patches were not really submitted properly.

If you post a series, the series goes to one destination and
one tree.

If they are supposed to go to multiple trees, submit them
individually rather than as a series.  With clear indications
in the Subject lines which tree should be taking the patch.

Thank you.

Re: [PATCH] crypto: n2 - cure use after free

[David Miller]

From: Jan Engelhardt 
Date: Tue, 19 Dec 2017 19:09:07 +0100

> queue_cache_init is first called for the Control Word Queue
> (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
> kmem_cache will be allocated. If the subsequent n2_register_algs call
> fails, the kmem_cache will be released in queue_cache_destroy, but
> queue_cache_init[0] is not set back to NULL.
> 
> So when the Module Arithmetic Unit gets probed next (n2_mau_probe),
> queue_cache_init will not allocate a kmem_cache again, but leave it
> as its bogus value, causing a BUG() to trigger when queue_cache[0] is
> eventually passed to kmem_cache_zalloc:
 ...
> Signed-off-by: Jan Engelhardt 

Acked-by: David S. Miller 

Re: [PATCH] crypto: n2 - cure use after free

[David Miller]

From: Jan Engelhardt 
Date: Tue, 19 Dec 2017 16:42:39 +0100 (CET)

> Nevertheless, I think that the error pathing in n2_core.c should be made 
> robust as well.

I completely agree.

> Should I resubmit with a new commit message?

Yes.

Re: [PATCH v2 2/2] chcr: Add support for Inline IPSec

[David Miller]

From: Atul Gupta 
Date: Thu,  9 Nov 2017 16:59:01 +0530

> register xfrmdev_ops callbacks, Send IPsec tunneled data
> to HW for inline processing.
> The driver use hardware crypto accelerator to encrypt and
> generate ICV for the transmitted packet in Inline mode.
> 
> Signed-off-by: Atul Gupta 
> Signed-off-by: Harsh Jain 
> Signed-off-by: Ganesh Goudar 
> ---
> V2: Fixed the build warnings and created patch against cryptodev
> to avoid possible merge conflicts

Herbert, feel free to merge these two patches via your crypto
tree.

Thanks!

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

[David Miller]

From: Herbert Xu 
Date: Thu, 5 Oct 2017 11:40:54 +0800

> On Tue, Oct 03, 2017 at 07:45:06PM -0300, Marcelo Ricardo Leitner wrote:
>>
>> > Usually if you're invoking setkey from a non-sleeping code-path
>> > you're probably doing something wrong.
>> 
>> Usually but not always. There are 3 calls to that function on SCTP
>> code:
>> - pack a cookie, which is sent on an INIT_ACK packet to the client
>> - unpack the cookie above, after it is sent back by the client on a
>>   COOKIE_ECHO packet
>> - send a chunk authenticated by a hash
> 
> I'm not talking about the code-path in question.  I'm talking
> about the function which generates the secret key in the first
> place.  AFAICS that's only called in GFP_KERNEL context.  What
> am I missing?

The setkey happens in functions like sctp_pack_cookie() and
sctp_unpack_cookie(), which seems to run from software interrupts.

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[David Miller]

From: Allen Pais 
Date: Wed, 13 Sep 2017 13:02:15 +0530

> Signed-off-by: Allen Pais 

This is quite pointless as the caller doesn't do anything with
the value, it just tests whether a negative value is returned
or not.

Re: [PATCH 1/2] crypto: n2 - remove null check before kfree

[David Miller]

From: Himanshu Jha 
Date: Sun, 27 Aug 2017 02:45:29 +0530

> kfree on NULL pointer is a no-op and therefore checking it is redundant.
> 
> Signed-off-by: Himanshu Jha 

Acked-by: David S. Miller 

Re: [PATCH] crypto: n2_core: Convert to using %pOF instead of full_name

[David Miller]

From: Rob Herring 
Date: Tue, 18 Jul 2017 16:42:56 -0500

> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 

Acked-by: David S. Miller 

Re: [GIT] Networking

[David Miller]

From: Herbert Xu 
Date: Mon, 10 Jul 2017 22:00:48 +0800

> crypto: af_alg - Avoid sock_graft call warning
> 
> The newly added sock_graft warning triggers in af_alg_accept.
> It's harmless as we're essentially doing sock->sk = sock->sk.
> 
> The sock_graft call is actually redundant because all the work
> it does is subsumed by sock_init_data.  However, it was added
> to placate SELinux as it uses it to initialise its internal state.
> 
> This patch avoisd the warning by making the SELinux call directly.
> 
> Reported-by: Linus Torvalds 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 

Looks good, is this going via my tree or your's?

Re: [PATCH] crypto: cavium: make several functions static

[David Miller]

From: Colin King 
Date: Tue, 20 Jun 2017 11:35:50 +0100

> From: Colin Ian King 
> 
> The functions cvm_encrypt, cvm_decrypt, cvm_xts_setkey and
> cvm_enc_dec_init does not need to be in global scope, so make
> them static.
> 
> Signed-off-by: Colin Ian King 

Acked-by: David S. Miller 

Re: Crypto Fixes for 4.12

[David Miller]

From: Theodore Ts'o <ty...@mit.edu>
Date: Fri, 16 Jun 2017 08:50:07 -0400

> On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote:
>> As a side note, ext4 does something similar with a private
>> implementation, but it doesn't use something the evaluates to an
>> alloca.  Instead it uses a fixed 4-byte size for the shash context
>> value in the on-stack declaration.
> 
> In ext4's case, we're doing it inside an inline function, and then
> using the "return" value from inside the calling function.  Assuming
> that gcc actually inlines the function, are we in danger of tripping
> over the bug?

Again, the bug can only be triggered if you do a dynamically sized
object on the stack.

Which ext4 is not doing, since it uses fixed size elements in the
on-stack shash context.

Re: [PATCH v3 net-next 0/4] kernel TLS

[David Miller]

From: Dave Watson 
Date: Wed, 14 Jun 2017 11:36:54 -0700

> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
> 
> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
> 
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
> 
> RFC patch to openssl:
> https://mta.openssl.org/pipermail/openssl-dev/2017-June/009384.html
 ...

Series applied, thanks for all of this hard work!

Re: [PATCH] crypto: n2: make of_device_ids const

[David Miller]

From: Arvind Yadav 
Date: Thu, 15 Jun 2017 17:28:10 +0530

> of_device_ids are not supposed to change at runtime. All functions
> working with of_device_ids provided by  work with const
> of_device_ids. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>2001  2168  4842171079 drivers/crypto/n2_core.o
> 
> File size after constify dummy_tlb_ops.:
>text  data bss dec hex filename
>3601   536  4841851059 drivers/crypto/n2_core.o
> 
> Signed-off-by: Arvind Yadav 

Acked-by: David S. Miller 

Re: Crypto Fixes for 4.12

[David Miller]

From: Linus Torvalds 
Date: Thu, 15 Jun 2017 18:04:44 +0900

> There's a fair number of SHASH_DESC_ON_STACK users, are all the others
> safe for some random reason that just happens to be about code
> generation? Did people actually verify that?

I looked at the code generated in every case.

As a side note, ext4 does something similar with a private
implementation, but it doesn't use something the evaluates to an
alloca.  Instead it uses a fixed 4-byte size for the shash context
value in the on-stack declaration.

We can tidy it up with abstraction macros as a follow-up, thanks
for the suggestion.  I'll look into it.

Re: Crypto Fixes for 4.12

[David Miller]

From: Herbert Xu 
Date: Thu, 15 Jun 2017 17:42:10 +0800

> On Thu, Jun 15, 2017 at 06:04:44PM +0900, Linus Torvalds wrote:
>> There's a fair number of SHASH_DESC_ON_STACK users, are all the others
>> safe for some random reason that just happens to be about code
>> generation? Did people actually verify that?
> 
> If I understand this correctly this is only an issue if you directly
> return a value from the shash_desc struct allocated on the stack.
> This is usually rare as normally you'd return an error code and the
> hash result would be written directly to some memory passed in from
> the caller.

Correct.

Re: [PATCH v3 net-next 0/4] kernel TLS

[David Miller]

From: Dave Watson 
Date: Wed, 14 Jun 2017 11:36:54 -0700

> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
> 
> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
> 
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
> 
> RFC patch to openssl:
> https://mta.openssl.org/pipermail/openssl-dev/2017-June/009384.html
 ...

I really want to apply this, so everyone give it a good review :-)

Re: Crypto Fixes for 4.12

[David Miller]

From: Herbert Xu 
Date: Thu, 8 Jun 2017 17:23:21 +0800

> This push fixes a couple of places in the crypto code that were
> doing interruptible sleeps dangerously.  They have been converted
> to use non-interruptible sleeps.  This push also fixes a bug in
> asymmetric_keys where it would trigger a use-after-free if a
> request returned EBUSY due to a full device queue.

Where is the gcc shash miscompile workaround?

Thanks.

Re: [PATCH v2 net-next 1/4] tcp: ULP infrastructure

[David Miller]

From: Dave Watson 
Date: Tue, 6 Jun 2017 10:00:20 -0700

> +EXPORT_SYMBOL(tcp_register_ulp);

EXPORT_SYMBOL_GPL() please.

> +EXPORT_SYMBOL(tcp_unregister_ulp);

Likewise.

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT)

> 
> On sparc, if we have an alloca() like situation, as is the case with
> SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
> memory.  The result can be that the value is clobbered if a trap
> or interrupt arrives at just the right instruction.
> 
> It only occurs if the function ends returning a value from that
> alloca() area and that value can be placed into the return value
> register using a single instruction.
> 
> For example, in lib/libcrc32c.c:crc32c() we end up with a return
> sequence like:
> 
> return  %i7+8
>  lduw   [%o5+16], %o0   ! MEM[(u32 *)__shash_desc.1_10 + 16B],
> 
> %o5 holds the base of the on-stack area allocated for the shash
> descriptor.  But the return released the stack frame and the
> register window.
> 
> So if an intererupt arrives between 'return' and 'lduw', then
> the value read at %o5+16 can be corrupted.
> 
> Add a data compiler barrier to work around this problem.  This is
> exactly what the gcc fix will end up doing as well, and it absolutely
> should not change the code generated for other cpus (unless gcc
> on them has the same bug :-)
> 
> With crucial insight from Eric Sandeen.
> 
> Reported-by: Anatoly Pugachev <mator...@gmail.com>
> Signed-off-by: David S. Miller <da...@davemloft.net>

Herbert, please take a look at this and push via your crypto tree
and submit to -stable if you don't have any objections.

Thanks!

> ---
> 
> See the thread anchored at:
> 
>   http://marc.info/?l=linux-sparc=149623182616944=2
> 
> for discussion, it has a reproducer module.  The problem was
> first noticed as occaisional XFS checksum corruptions.
> 
> Herbert, I don't expect you to like this but it is the best we can do
> I think.  It should not pessimize code on other architectures at all.
> I will work on fixing the gcc bug but it's been around forever and all
> versions are effected.
> 
> I noticed while working on this that at least btrfs duplicates the
> facilities provided by lib/libcrc32c.c and therefore should probably
> be converted over to straight crc32c() calls if possible.
> 
> Thanks!
> 
> diff --git a/drivers/infiniband/sw/rxe/rxe.h b/drivers/infiniband/sw/rxe/rxe.h
> index ecdba2f..1ac5b85 100644
> --- a/drivers/infiniband/sw/rxe/rxe.h
> +++ b/drivers/infiniband/sw/rxe/rxe.h
> @@ -68,6 +68,7 @@
>  static inline u32 rxe_crc32(struct rxe_dev *rxe,
>   u32 crc, void *next, size_t len)
>  {
> + u32 retval;
>   int err;
>  
>   SHASH_DESC_ON_STACK(shash, rxe->tfm);
> @@ -81,7 +82,9 @@ static inline u32 rxe_crc32(struct rxe_dev *rxe,
>   return crc32_le(crc, next, len);
>   }
>  
> - return *(u32 *)shash_desc_ctx(shash);
> + retval = *(u32 *)shash_desc_ctx(shash);
> + barrier_data(shash_desc_ctx(shash));
> + return retval;
>  }
>  
>  int rxe_set_mtu(struct rxe_dev *rxe, unsigned int dev_mtu);
> diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
> index a97fdc1..baacc18 100644
> --- a/fs/btrfs/hash.c
> +++ b/fs/btrfs/hash.c
> @@ -38,6 +38,7 @@ u32 btrfs_crc32c(u32 crc, const void *address, unsigned int 
> length)
>  {
>   SHASH_DESC_ON_STACK(shash, tfm);
>   u32 *ctx = (u32 *)shash_desc_ctx(shash);
> + u32 retval;
>   int err;
>  
>   shash->tfm = tfm;
> @@ -47,5 +48,7 @@ u32 btrfs_crc32c(u32 crc, const void *address, unsigned int 
> length)
>   err = crypto_shash_update(shash, address, length);
>   BUG_ON(err);
>  
> - return *ctx;
> + retval = *ctx;
> + barrier_data(ctx);
> + return retval;
>  }
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 2185c7a..fd2e651 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1078,6 +1078,7 @@ static inline u32 f2fs_crc32(struct f2fs_sb_info *sbi, 
> const void *address,
>  {
>   SHASH_DESC_ON_STACK(shash, sbi->s_chksum_driver);
>   u32 *ctx = (u32 *)shash_desc_ctx(shash);
> + u32 retval;
>   int err;
>  
>   shash->tfm = sbi->s_chksum_driver;
> @@ -1087,7 +1088,9 @@ static inline u32 f2fs_crc32(struct f2fs_sb_info *sbi, 
> const void *address,
>   err = crypto_shash_update(shash, address, length);
>   BUG_ON(err);
>  
> - return *ctx;
> + retval = *ctx;
> + barrier_data(ctx);
> + return retval;
>  }
>  
>  static inline bool f2fs_crc_valid(struct f2fs_sb_info *sbi, __u32 blk_crc,
> diff --git a/lib/libcrc32c.c b/lib/libcrc32c.c
> index 74a54b7..9f79547 100644
> --- a/lib/libcrc32c.c
> +++ b/lib/libcrc32c.c
> @@ -43,7 +43,7 @@ s

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Fri, 02 Jun 2017 14:39:06 -0400 (EDT)

> From: "Darrick J. Wong" <darrick.w...@oracle.com>
> Date: Fri, 2 Jun 2017 11:08:08 -0700
> 
>> ext4/jbd2's crc32c implementations will also need a fix like this for
>> {ext4,jbd2}_chksum.  Note that both of these modules call the crypto api
>> directly to avoid a static dependence on libcrc32c; this was done to
>> reduce kernel footprint for applications that don't need it.  (ext2,
>> ext3, and ext4 before the metadata_csum feature existed).
> 
> Good catch.  I even looked at that code the other day so should
> have spotted it as well.
> 
> I'll integrate fixes for those into my patch when I get a chance,
> thanks!

Actually, ext4 doesn't trigger the problem because the on-stack object
used in ext4 is a fixed size at compile time.  Which is technically an
ill-advised assumption to make.  Even the generic libcrc32c.c doesn't
assume that the context area is 4 bytes for crc32c.

Anyways, back to the main point, the gcc bug only triggers when
alloca() like constructs are used.

That's why I scanned for SHASH_DESC_ON_STACK() to see exactly where
the workaround is necessary.

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

[David Miller]

From: "Darrick J. Wong" 
Date: Fri, 2 Jun 2017 11:08:08 -0700

> ext4/jbd2's crc32c implementations will also need a fix like this for
> {ext4,jbd2}_chksum.  Note that both of these modules call the crypto api
> directly to avoid a static dependence on libcrc32c; this was done to
> reduce kernel footprint for applications that don't need it.  (ext2,
> ext3, and ext4 before the metadata_csum feature existed).

Good catch.  I even looked at that code the other day so should
have spotted it as well.

I'll integrate fixes for those into my patch when I get a chance,
thanks!

crypto: Work around deallocated stack frame reference gcc bug on sparc.

[David Miller]

On sparc, if we have an alloca() like situation, as is the case with
SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
memory.  The result can be that the value is clobbered if a trap
or interrupt arrives at just the right instruction.

It only occurs if the function ends returning a value from that
alloca() area and that value can be placed into the return value
register using a single instruction.

For example, in lib/libcrc32c.c:crc32c() we end up with a return
sequence like:

return  %i7+8
 lduw   [%o5+16], %o0   ! MEM[(u32 *)__shash_desc.1_10 + 16B],

%o5 holds the base of the on-stack area allocated for the shash
descriptor.  But the return released the stack frame and the
register window.

So if an intererupt arrives between 'return' and 'lduw', then
the value read at %o5+16 can be corrupted.

Add a data compiler barrier to work around this problem.  This is
exactly what the gcc fix will end up doing as well, and it absolutely
should not change the code generated for other cpus (unless gcc
on them has the same bug :-)

With crucial insight from Eric Sandeen.

Reported-by: Anatoly Pugachev 
Signed-off-by: David S. Miller 
---

See the thread anchored at:

http://marc.info/?l=linux-sparc=149623182616944=2

for discussion, it has a reproducer module.  The problem was
first noticed as occaisional XFS checksum corruptions.

Herbert, I don't expect you to like this but it is the best we can do
I think.  It should not pessimize code on other architectures at all.
I will work on fixing the gcc bug but it's been around forever and all
versions are effected.

I noticed while working on this that at least btrfs duplicates the
facilities provided by lib/libcrc32c.c and therefore should probably
be converted over to straight crc32c() calls if possible.

Thanks!

diff --git a/drivers/infiniband/sw/rxe/rxe.h b/drivers/infiniband/sw/rxe/rxe.h
index ecdba2f..1ac5b85 100644
--- a/drivers/infiniband/sw/rxe/rxe.h
+++ b/drivers/infiniband/sw/rxe/rxe.h
@@ -68,6 +68,7 @@
 static inline u32 rxe_crc32(struct rxe_dev *rxe,
u32 crc, void *next, size_t len)
 {
+   u32 retval;
int err;
 
SHASH_DESC_ON_STACK(shash, rxe->tfm);
@@ -81,7 +82,9 @@ static inline u32 rxe_crc32(struct rxe_dev *rxe,
return crc32_le(crc, next, len);
}
 
-   return *(u32 *)shash_desc_ctx(shash);
+   retval = *(u32 *)shash_desc_ctx(shash);
+   barrier_data(shash_desc_ctx(shash));
+   return retval;
 }
 
 int rxe_set_mtu(struct rxe_dev *rxe, unsigned int dev_mtu);
diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
index a97fdc1..baacc18 100644
--- a/fs/btrfs/hash.c
+++ b/fs/btrfs/hash.c
@@ -38,6 +38,7 @@ u32 btrfs_crc32c(u32 crc, const void *address, unsigned int 
length)
 {
SHASH_DESC_ON_STACK(shash, tfm);
u32 *ctx = (u32 *)shash_desc_ctx(shash);
+   u32 retval;
int err;
 
shash->tfm = tfm;
@@ -47,5 +48,7 @@ u32 btrfs_crc32c(u32 crc, const void *address, unsigned int 
length)
err = crypto_shash_update(shash, address, length);
BUG_ON(err);
 
-   return *ctx;
+   retval = *ctx;
+   barrier_data(ctx);
+   return retval;
 }
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 2185c7a..fd2e651 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1078,6 +1078,7 @@ static inline u32 f2fs_crc32(struct f2fs_sb_info *sbi, 
const void *address,
 {
SHASH_DESC_ON_STACK(shash, sbi->s_chksum_driver);
u32 *ctx = (u32 *)shash_desc_ctx(shash);
+   u32 retval;
int err;
 
shash->tfm = sbi->s_chksum_driver;
@@ -1087,7 +1088,9 @@ static inline u32 f2fs_crc32(struct f2fs_sb_info *sbi, 
const void *address,
err = crypto_shash_update(shash, address, length);
BUG_ON(err);
 
-   return *ctx;
+   retval = *ctx;
+   barrier_data(ctx);
+   return retval;
 }
 
 static inline bool f2fs_crc_valid(struct f2fs_sb_info *sbi, __u32 blk_crc,
diff --git a/lib/libcrc32c.c b/lib/libcrc32c.c
index 74a54b7..9f79547 100644
--- a/lib/libcrc32c.c
+++ b/lib/libcrc32c.c
@@ -43,7 +43,7 @@ static struct crypto_shash *tfm;
 u32 crc32c(u32 crc, const void *address, unsigned int length)
 {
SHASH_DESC_ON_STACK(shash, tfm);
-   u32 *ctx = (u32 *)shash_desc_ctx(shash);
+   u32 ret, *ctx = (u32 *)shash_desc_ctx(shash);
int err;
 
shash->tfm = tfm;
@@ -53,7 +53,9 @@ u32 crc32c(u32 crc, const void *address, unsigned int length)
err = crypto_shash_update(shash, address, length);
BUG_ON(err);
 
-   return *ctx;
+   ret = *ctx;
+   barrier_data(ctx);
+   return ret;
 }
 
 EXPORT_SYMBOL(crc32c);

Re: [sparc64] crc32c misbehave

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Wed, 31 May 2017 11:53:35 -0400 (EDT)

> Can you try something like disabling cpu IRQs around the crc32c() function
> in lib/libcrc32c.c?  Something like:
> 
>   u32 retval;
> 
>   local_irq_disable();
> 
>   shash->tfm = tfm;
>   shash->flags = 0;
>   *ctx = crc;
> 
>   err = crypto_shash_update(shash, address, length);
>   BUG_ON(err);
> 
>   retval = *ctx;
> 
>   local_irq_enable();
> 
>   return retval;

Actually you would need a spinlock, with IRQs disabled, to properly test
this theory since the TFM is shared across the entire system.

The really suspicious part of your test results is that the corrupted
checksum always evaluates to zero.

Re: [sparc64] crc32c misbehave

[David Miller]

From: Anatoly Pugachev 
Date: Wed, 31 May 2017 14:56:52 +0300

> While debugging occasional crc32c checksum errors with xfs disk reads on
> sparc64 (T5 [sun4v] 3.6 GHz CPU ldom, debian unstable/sid), Eric have found
> that crc32c sometimes returns wrong checksum for data. Eric made a simple
> test kernel module (included), which produce the following results on my
> sparc64 machines:

I don't think that crc32c() is thread safe because of the way it is
implemented with a shared TFM crypto object allocated once at boot
time.

I think you are seeing the corruption any time an interrupt comes in
on the same cpu as your test module is running on and does a crc32c()
calculation, corrupting the context key value being used by your
invocation.

At least that's my guess, I could have misread how the key is stored
and managed around operations.

Can you try something like disabling cpu IRQs around the crc32c() function
in lib/libcrc32c.c?  Something like:

u32 retval;

local_irq_disable();

shash->tfm = tfm;
shash->flags = 0;
*ctx = crc;

err = crypto_shash_update(shash, address, length);
BUG_ON(err);

retval = *ctx;

local_irq_enable();

return retval;

Thanks.

Re: [PATCH net-next 3/4] tls: kernel TLS support

[David Miller]

From: Eric Dumazet 
Date: Fri, 26 May 2017 07:16:59 -0700

> On Wed, 2017-05-24 at 09:27 -0700, Dave Watson wrote:
>> Software implementation of transport layer security, implemented using ULP
>> infrastructure.  tcp proto_ops are replaced with tls equivalents of sendmsg 
>> and
>> sendpage.
> 
> ...
> 
>> +
>> +int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>> +{
>   ...
>> +
>> +lock_sock(sk);
>> +
>> +/* Only one writer at a time is allowed */
>> +if (sk->sk_write_pending)
>> +return -EBUSY;
> 
> Ouch...

Well, as I understand it, it is the same restriction userspace must
itself enforce either in the application or in the SSL library.

Re: [PATCH net-next 0/4] kernel TLS

[David Miller]

From: Dave Watson 
Date: Wed, 24 May 2017 09:26:33 -0700

> This series adds support for kernel TLS encryption over TCP sockets.
> A standard TCP socket is converted to a TLS socket using a setsockopt.
> Only symmetric crypto is done in the kernel, as well as TLS record
> framing.  The handshake remains in userspace, and the negotiated
> cipher keys/iv are provided to the TCP socket.
> 
> We implemented support for this API in OpenSSL 1.1.0, the code is
> available at https://github.com/Mellanox/tls-openssl/tree/master
> 
> It should work with any TLS library with similar modifications,
> a test tool using gnutls is here: https://github.com/Mellanox/tls-af_ktls_tool
> 
> Changes from RFC V2:
> 
> * Generic ULP (upper layer protocol) framework instead of TLS specific
>   setsockopts
> * Dropped Mellanox hardware patches, will come as separate series.
>   Framework will work for both.

The value in this is seeing how it can work transparently behind
an existing userspace library providing TLS services.

So the reference to the gnutls and openssl implementations probably
belongs in the Documentation patch #4 too.

Thanks.

Re: [PATCH net-next 2/4] tcp: export do_tcp_sendpages and tcp_rate_check_app_limited functions

[David Miller]

From: Dave Watson 
Date: Wed, 24 May 2017 09:26:57 -0700

> Export do_tcp_sendpages and tcp_rate_check_app_limited, since tls will need to
> sendpages while the socket is already locked.
> 
> tcp_sendpage is exported, but requires the socket lock to not be held already.
> 
> Signed-off-by: Aviad Yehezkel 
> Signed-off-by: Ilya Lesokhin 
> Signed-off-by: Boris Pismenny 
> Signed-off-by: Dave Watson 
 ...
> +EXPORT_SYMBOL(do_tcp_sendpages);
 ...
> +EXPORT_SYMBOL(tcp_rate_check_app_limited);

These need to both be EXPORT_SYMBOL_GPL().

Re: [PATCH] crypto: hifn_795x: Fix a handful of minor bugs spotted by eye

[David Miller]

From: Logan Gunthorpe 
Date: Wed, 17 May 2017 21:33:22 -0600

> 
> 
> On 17/05/17 09:26 PM, Herbert Xu wrote:
>> On Thu, May 18, 2017 at 11:25:06AM +0800, Herbert Xu wrote:
>>> On Fri, Apr 28, 2017 at 11:02:40AM -0600, Logan Gunthorpe wrote:
 * Cleaned up the formatting of ablkcipher_get arguments so it complies
   with kernel style
 * The offset in ablkcipher_get sould be added to the source, not the
   destination. We rename it to soffset for clarity.
 * dst++ should be dst=sg_next(dst)
 * We call kunmap_atomic earlier so we only have to do it once.
 * If ablkcipher_get fails, we should probably ensure the request
   completes with an error.
> 
>>> Please don't mix unrelated changes in the same patch.
> 
> Seriously? The patch is tiny and those are all incredibly minor changes.

Yes, seriously.

It is the only way to make your changes easy to review and audit.

Please do as Herbert is asking.

Re: [PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

[David Miller]

From: Herbert Xu 
Date: Fri, 21 Apr 2017 19:36:41 +0800

> On Wed, Apr 19, 2017 at 11:11:35AM +0200, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Wed, 19 Apr 2017 10:50:04 +0200
>> 
>> The script "checkpatch.pl" pointed information out like the following.
>> 
>> WARNING: quoted string split across lines
>> 
>> Thus fix the affected source code places.
>> 
>> Signed-off-by: Markus Elfring 
> 
> This patch doesn't seem to add any value so I'm not taking it.
> 
> Please don't send patches based purely on a checkpatch complaint.

Thank you Herbert.

Re: [patch V2 13/13] crypto: n2 - Replace racy task affinity logic

[David Miller]

From: Thomas Gleixner 
Date: Thu, 13 Apr 2017 10:20:23 +0200 (CEST)

> spu_queue_register() needs to invoke setup functions on a particular
> CPU. This is achieved by temporarily setting the affinity of the
> calling user space thread to the requested CPU and reset it to the original
> affinity afterwards.
> 
> That's racy vs. CPU hotplug and concurrent affinity settings for that
> thread resulting in code executing on the wrong CPU and overwriting the
> new affinity setting.
> 
> Replace it by using work_on_cpu_safe() which guarantees to run the code on
> the requested CPU or to fail in case the CPU is offline.
> 
> Signed-off-by: Thomas Gleixner 
> Acked-by: Herbert Xu 

Acked-by: David S. Miller 

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

[David Miller]

From: Herbert Xu 
Date: Thu, 6 Apr 2017 16:15:09 +0800

> As the final patch depends on all three it would be easiest if
> we pushed the xfrm patch through the crypto tree.  Steffen/David?

No objections from me for this going through the crypto tree.

Re: [RFC TLS Offload Support 00/15] cover letter

[David Miller]

From: Aviad Yehezkel 
Date: Tue, 28 Mar 2017 16:26:17 +0300

> TLS Tx crypto offload is a new feature of network devices. It
> enables the kernel TLS socket to skip encryption and authentication
> operations on the transmit side of the data path, delegating those
> to the NIC. In turn, the NIC encrypts packets that belong to an
> offloaded TLS socket on the fly. The NIC does not modify any packet
> headers. It expects to receive fully framed TCP packets with TLS
> records as payload. The NIC replaces plaintext with ciphertext and
> fills the authentication tag. The NIC does not hold any state beyond
> the context needed to encrypt the next expected packet,
> i.e. expected TCP sequence number and crypto state.

It seems like, since you do the TLS framing in TCP and the card is
expecting to fill in certain aspects, there is a requirement that the
packet contents aren't mangled between the TLS framing code and when
the SKB hits the card.

Is this right?

For example, what happens if netfilter splits a TLS Tx offloaded frame
into two TCP segments?

Re: [PATCH] padata: avoid race in reordering

[David Miller]

From: Steffen Klassert 
Date: Fri, 24 Mar 2017 10:41:59 +0100

> On Thu, Mar 23, 2017 at 12:24:43PM +0100, Jason A. Donenfeld wrote:
>> Under extremely heavy uses of padata, crashes occur, and with list
>> debugging turned on, this happens instead:
 ...
>> Signed-off-by: Jason A. Donenfeld 
> 
> Acked-by: Steffen Klassert 

Herbert, this should probably go via your crypto tree.

Re: [PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure

[David Miller]

From: Eric Biggers 
Date: Thu, 23 Mar 2017 13:39:46 -0700

> From: Eric Biggers 
> 
> In the generic XTS and LRW algorithms, for input data > 128 bytes, a
> temporary buffer is allocated to hold the values to be XOR'ed with the
> data before and after encryption or decryption.  If the allocation
> fails, the fixed-size buffer embedded in the request buffer is meant to
> be used as a fallback --- resulting in more calls to the ECB algorithm,
> but still producing the correct result.  However, we weren't correctly
> limiting subreq->cryptlen in this case, resulting in pre_crypt()
> overrunning the embedded buffer.  Fix this by setting subreq->cryptlen
> correctly.
> 
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
> Cc: sta...@vger.kernel.org # v4.10+
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Eric Biggers 

Acked-by: David S. Miller 

Re: [PATCH] crypto: ixp4xx - Use sg_virt()

[David Miller]

From: Geliang Tang 
Date: Thu, 23 Mar 2017 21:16:30 +0800

> Use sg_virt() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 

Acked-by: David S. Miller 

Re: [PATCH v7 0/5] Update LZ4 compressor module

[David Miller]

From: Eric Biggers <ebigge...@gmail.com>
Date: Thu, 9 Feb 2017 10:29:14 -0800

> On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote:
>> > 
>> > [Also, for some reason linux-crypto is apparently still not receiving 
>> > patch 1/5
>> > in the series.  It's missing from the linux-crypto archive at
>> > http://www.spinics.net/lists/linux-crypto/, so it's not just me.]
>> > 
>> 
>> I don't really know what to do about this. I think the matter is the size of 
>> the E-Mail.
>> Are there filters or something like that? Since in linux-kernel the patch 
>> seems to get delivered.
>> I could otherwise CC you if you wish.
>> 
> 
> If I'm not mistaken, David Miller is the admin of the mail server on
> vger.kernel.org, and he already happens to be Cc'ed on this thread, so maybe 
> he
> can answer as to why linux-crypto may be configured differently?
> 
> Anyway, since the patch did make it to linux-kernel anyone can still download 
> it
> from patchwork if they know where to look:
> https://patchwork.kernel.org/patch/9556271/

I've increased the maxlength parameter for linux-cryto so this doesn't
happen again.

Re: [sparc64] cryptomgr_test OOPS kernel 4.9.0+

[David Miller]

From: Anatoly Pugachev 
Date: Sun, 25 Dec 2016 20:56:08 +0300

> Disabling kernel config option
> CRYPTO_MANAGER_DISABLE_TESTS
> i.e. enable run-time self tests, makes kernel unbootable:
> 
> tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9

I think the testing code for the new synchronous compression module is
putting kernel image pointers into scatterlists, which in turn we
attempt to transform to and from page structs.

That doesn't work.

It's coming from the test input buffers:

static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
  struct comp_testvec *dtemplate, int ctcount, int dtcount)
{
 ...
sg_init_one(, ctemplate[i].input, ilen);

These have to be copied into kmalloc() buffers or similar, just like
the skchiper tests do.

The crash on sparc64 shows that we try to dereference a page struct at
a bogus vmemmap address for a page that doesn't exist.

I hacked up the following and this makes the crashes go away:

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f616ad7..117bb33 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1449,22 +1449,31 @@ static int test_acomp(struct crypto_acomp *tfm, struct 
comp_testvec *ctemplate,
const char *algo = crypto_tfm_alg_driver_name(crypto_acomp_tfm(tfm));
unsigned int i;
char *output;
+   char *input;
int ret;
struct scatterlist src, dst;
struct acomp_req *req;
struct tcrypt_result result;
 
+   pr_info("test_acomp: COMP_BUF_SIZE %d\n", (int) COMP_BUF_SIZE);
+
output = kmalloc(COMP_BUF_SIZE, GFP_KERNEL);
if (!output)
return -ENOMEM;
+   input = kmalloc(COMP_BUF_SIZE, GFP_KERNEL);
+   if (!input) {
+   kfree(output);
+   return -ENOMEM;
+   }
 
for (i = 0; i < ctcount; i++) {
unsigned int dlen = COMP_BUF_SIZE;
int ilen = ctemplate[i].inlen;
 
memset(output, 0, dlen);
+   memcpy(input, ctemplate[i].input, ilen);
init_completion();
-   sg_init_one(, ctemplate[i].input, ilen);
+   sg_init_one(, input, ilen);
sg_init_one(, output, dlen);
 
req = acomp_request_alloc(tfm);
@@ -1512,8 +1521,9 @@ static int test_acomp(struct crypto_acomp *tfm, struct 
comp_testvec *ctemplate,
int ilen = dtemplate[i].inlen;
 
memset(output, 0, dlen);
+   memcpy(input, dtemplate[i].input, ilen);
init_completion();
-   sg_init_one(, dtemplate[i].input, ilen);
+   sg_init_one(, input, ilen);
sg_init_one(, output, dlen);
 
req = acomp_request_alloc(tfm);
@@ -1559,6 +1569,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct 
comp_testvec *ctemplate,
ret = 0;
 
 out:
+   kfree(input);
kfree(output);
return ret;
 }
--
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: [sparc64] cryptomgr_test OOPS kernel 4.9.0+

[David Miller]

From: Anatoly Pugachev 
Date: Sun, 25 Dec 2016 20:56:08 +0300

> Disabling kernel config option
> CRYPTO_MANAGER_DISABLE_TESTS
> i.e. enable run-time self tests, makes kernel unbootable:
> 
> tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9

I'm getting this with the current GIT tree too, will try to see
what's going wrong.
--
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 3/4] secure_seq: use siphash24 instead of md5_transform

[David Miller]

From: "Jason A. Donenfeld" 
Date: Wed, 14 Dec 2016 13:53:10 +0100

> In all current uses of __packed in the code, I think the impact is
> precisely zero, because all structures have members in descending
> order of size, with each member being a perfect multiple of the one
> below it. The __packed is therefore just there for safety, in case
> somebody comes in and screws everything up by sticking a u8 in
> between.

Just marking the structure __packed, whether necessary or not, makes
the compiler assume that the members are not aligned and causes
byte-by-byte accesses to be performed for words.

Never, _ever_, use __packed unless absolutely necessary, it pessimizes
the code on cpus that require proper alignment of types.
--
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 net-next] cxgb4: Allocate Tx queues dynamically

[David Miller]

From: Atul Gupta 
Date: Fri, 18 Nov 2016 16:37:40 +0530

> From: Hariprasad Shenai 
> 
> Allocate resources dynamically for Upper layer driver's (ULD) like
> cxgbit, iw_cxgb4, cxgb4i and chcr. The resources allocated include Tx
> queues which are allocated when ULD register with cxgb4 driver and freed
> while un-registering. The Tx queues which are shared by ULD shall be
> allocated by first registering driver and un-allocated by last
> unregistering driver.
> 
> Signed-off-by: Atul Gupta 

Applied.
--
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] poly1305: generic C can be faster on chips with slow unaligned access

[David Miller]

From: "Jason A. Donenfeld" 
Date: Thu, 3 Nov 2016 08:24:57 +0100

> Hi Herbert,
> 
> On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu  
> wrote:
>> FWIW I'd rather live with a 6% slowdown than having two different
>> code paths in the generic code.  Anyone who cares about 6% would
>> be much better off writing an assembly version of the code.
> 
> Please think twice before deciding that the generic C "is allowed to
> be slow".

In any event no piece of code should be doing 32-bit word reads from
addresses like "x + 3" without, at a very minimum, going through the
kernel unaligned access handlers.

Yet that is what the generic C poly1305 code is doing, all over the
place.

We know explicitly that these offsets will not be 32-bit aligned, so
it is required that we use the helpers, or alternatively do things to
avoid these unaligned accesses such as using temporary storage when
the HAVE_EFFICIENT_UNALIGNED_ACCESS kconfig value is not set.
--
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 net-next] chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's

[David Miller]

From: Hariprasad Shenai 
Date: Sat, 17 Sep 2016 08:12:39 +0530

> Allocate resources dynamically to cxgb4's Upper layer driver's(ULD) like
> cxgbit, iw_cxgb4 and cxgb4i. Allocate resources when they register with
> cxgb4 driver and free them while unregistering. All the queues and the
> interrupts for them will be allocated during ULD probe only and freed
> during remove.
> 
> Signed-off-by: Hariprasad Shenai 

Applied.
--
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: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

[David Miller]

From: Herbert Xu <herb...@gondor.apana.org.au>
Date: Fri, 19 Aug 2016 14:15:43 +0800

> On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote:
>> From: Hariprasad Shenai <haripra...@chelsio.com>
>> Date: Wed, 17 Aug 2016 12:33:02 +0530
>> 
>> > This patch series adds support for Chelsio Crypto driver. 
>> 
>> Herbert, what do you want to do with this?  I can push it via
>> net-next if you like.
> 
> Sure thing, the crypto part looks good to me.  Thanks Dave!

Great, done.
--
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: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

[David Miller]

From: Hariprasad Shenai 
Date: Wed, 17 Aug 2016 12:33:02 +0530

> This patch series adds support for Chelsio Crypto driver. 

Herbert, what do you want to do with this?  I can push it via
net-next if you like.
--
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: AF_ALG broken?

[David Miller]

From: Russell King - ARM Linux 
Date: Mon, 8 Aug 2016 23:58:51 +0100

> I don't know, but this seems to go completely against Linus' no
> userspace regressions, which seems to be an absolute requirement of
> all kernel development... Linus flames people for arguing against
> that rule!

Reading the explanation for the change given to you, it's impossible
for some hash algorithms to function properly without being given the
key first, and would crash.

Therefore the requirement is reasonable, even though it is unfortunate
that a critical piece of userspace infrastructure was coded this way.
--
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 2/3] chcr: Support for Chelsio's Crypto Hardware

[David Miller]

From: Yeshaswi M R Gowda 
Date: Mon, 18 Jul 2016 22:42:14 -0700

> +config CRYPTO_DEV_CHELSIO
> + tristate "Chelsio Crypto Co-processor Driver"
> + depends on PCI && NETDEVICES && ETHERNET
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_SHA512
> + select NET_VENDOR_CHELSIO
> + select CHELSIO_T4

The user shouldn't have to know about the technical details about
how this chip is physically implemented.

It's therefore not reasonable to require an ethernet driver to be
enabled to use the crypto engine.

Also, selecting Kconfig symbol X does not recursively enable the
"select" statement(s) of symbol X nor does it check symbol X's
dependencies.

This is really one big huge dependency mess, and I think you have
to split out the core of the T4 driver into a driver subtype
agnostic library or similar to make this work properly.

Don't just shoehorn this stuff into the ethernet driver.  Round
peg, square hole.

--
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: [sparc] niagara2 cpu, opcodes not available message?

[David Miller]

From: Anatoly Pugachev 
Date: Wed, 8 Jun 2016 20:30:40 +0300

> Can someone please tell, why do we get a bunch of the following
> messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220,
> T5140, and T5240 servers)
> 
> Asking, because I see the following lines on kernel boot (removing
> first field boot time stamp in cut):
> 
> mator@nvg5120:~/linux-sparc-boot-logs/t5120$ grep opcode
> dmesg-4.7.0-rc2+.log  | cut -f2- -d' ' | sort | uniq -c
>   4 aes_sparc64: sparc64 aes opcodes not available.
>   7 camellia_sparc64: sparc64 camellia opcodes not available.
>  37 crc32c_sparc64: sparc64 crc32c opcode not available.
>   5 des_sparc64: sparc64 des opcodes not available.
>   4 md5_sparc64: sparc64 md5 opcode not available.
>   1 sha1_sparc64: sparc64 sha1 opcode not available.
>   2 sha256_sparc64: sparc64 sha256 opcode not available.
>   3 sha512_sparc64: sparc64 sha512 opcode not available.

Because the drivers unconditionally try to load, check the CPU capabilites
and emit the log message if the cpu caps aren't present.

I don't see what the problem is, everying is working as designed.
--
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: [crypto / sparc64] cryptomgr_test OOPS

[David Miller]

From: Herbert Xu 
Date: Thu, 5 May 2016 16:42:49 +0800

> Subject: crypto: testmgr - Use kmalloc memory for RSA input
> 
> As akcipher uses an SG interface, you must not use vmalloc memory
> as input for it.  This patch fixes testmgr to copy the vmalloc
> test vectors to kmalloc memory before running the test.
> 
> This patch also removes a superfluous sg_virt call in do_test_rsa.
> 
> Cc: 
> Reported-by: Anatoly Pugachev 
> Signed-off-by: Herbert Xu 

I'm really surprised this didn't trigger on non-sparc64 systems, but
what do I know :-)
--
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: [crypto / sparc64] cryptomgr_test OOPS

[David Miller]

From: Anatoly Pugachev 
Date: Wed, 4 May 2016 22:10:47 +0300

> Here's a quick diff related to crypto for debian kernel configs:
> 
> $ diff -u /boot/config-4.5.0-2-sparc64-smp /boot/config-4.6.0-rc5-sparc64-smp
> @@ -5299,10 +5380,9 @@
>  CONFIG_CRYPTO_RNG=m
>  CONFIG_CRYPTO_RNG2=y
>  CONFIG_CRYPTO_RNG_DEFAULT=m
> -CONFIG_CRYPTO_PCOMP=m
> -CONFIG_CRYPTO_PCOMP2=y
>  CONFIG_CRYPTO_AKCIPHER2=y
> -# CONFIG_CRYPTO_RSA is not set
> +CONFIG_CRYPTO_AKCIPHER=y
> +CONFIG_CRYPTO_RSA=y
>  CONFIG_CRYPTO_MANAGER=y
>  CONFIG_CRYPTO_MANAGER2=y
>  # CONFIG_CRYPTO_USER is not set
> 
> so, I need to compile 4.5.x kernel (or even older kernels) with
> CRYPTO_RSA=y and test how it would act.

Well yes, that would be an absolutely critical datapoint.

--
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: [crypto / sparc64] cryptomgr_test OOPS

[David Miller]

From: Anatoly Pugachev 
Date: Tue, 3 May 2016 16:54:18 +0300

> I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not
> happen, if I set the following kernel option:
> 
> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
> 
> Can someone please look at https://bugzilla.kernel.org/show_bug.cgi?id=117551 
> ?

The lib/mpi/ code hasn't been touched in a long time, so I can only see that it 
might
be the crypto/rsa.c changes that happened this release.

Can you possibly bisect this or at least tell us that 4.5 doesn't have this 
problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs

[David Miller]

From: Anatoly Pugachev 
Date: Mon, 25 Jan 2016 19:09:39 +0300

> n2rng: Attach on T5/M5, T7/M7 SPARC CPUs
> 
> Signed-off-by: Anatoly Pugachev 

Acked-by: David S. Miller 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] n2rng: documentation, add DT bindings, vendor prefixes

[David Miller]

From: Anatoly Pugachev 
Date: Mon, 25 Jan 2016 19:09:21 +0300

> n2rng: documentation, add DT bindings, vendor prefixes
> 
> Signed-off-by: Anatoly Pugachev 

Acked-by: David S. Miller 
--
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 19/26] ipsec: Use skcipher and ahash when probing algorithms

[David Miller]

From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:19:11 +0800

> This patch removes the last reference to hash and ablkcipher from
> IPsec and replaces them with ahash and skcipher respectively.  For
> skcipher there is currently no difference at all, while for ahash
> the current code is actually buggy and would prevent asynchronous
> algorithms from being discovered.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 
--
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 25/26] sctp: Use shash

[David Miller]

From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:20:12 +0800

> This patch replaces uses of the long obsolete hash interface with
> shash.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 
--
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 26/26] tcp: Use ahash

[David Miller]

From: Herbert Xu 
Date: Sun, 24 Jan 2016 21:20:23 +0800

> This patch replaces uses of the long obsolete hash interface with
> ahash.
> 
> Signed-off-by: Herbert Xu 

Acked-by: David S. Miller 
--
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] net: fix uninitialized variable issue

[David Miller]

From: Tadeusz Struk 
Date: Tue, 15 Dec 2015 10:46:17 -0800

> msg_iocb needs to be initialized on the recv/recvfrom path.
> Otherwise afalg will wrongly interpret it as an async call.
> 
> Cc: sta...@vger.kernel.org
> Reported-by: Harald Freudenberger 
> Signed-off-by: Tadeusz Struk 

Looks good, applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

[David Miller]

From: Herbert Xu 
Date: Wed, 9 Dec 2015 16:44:58 +0800

> On Wed, Dec 09, 2015 at 02:13:32PM +0530, Rameshwar Sahu wrote:
>>
>> Yes, we are not upstream in-kernel users right now, but later client
>> ma upstream there patches.
> 
> Well I'd prefer to not take any crypto drivers that don't have
> in-kernel users.

+1
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipsec impact on performance

[David Miller]

From: Sowmini Varadhan 
Date: Tue, 1 Dec 2015 12:59:53 -0500

> I instrumented iperf with and without ipsec, just using esp-null, 
> and 1 thread, to keep things simple. I'm seeing some pretty dismal 
> performance numbers with ipsec, and trying to think of ways to
> improve this. Here are my findings, please share feedback.

Doesn't skb_cow_data() contribute significantly to the ESP base cost,
especially for TCP packets?

I mean, we're copying every TCP data frame.

If this is the case, even with GSO/whatever offloads, I expect that
performance will be roughly halfed.
--
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: n2 - Use platform_register/unregister_drivers()

[David Miller]

From: Thierry Reding 
Date: Wed,  2 Dec 2015 17:16:36 +0100

> From: Thierry Reding 
> 
> These new helpers simplify implementing multi-driver modules and
> properly handle failure to register one driver by unregistering all
> previously registered drivers.
> 
> Signed-off-by: Thierry Reding 

Acked-by: David S. Miller 
--
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 net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

[David Miller]

From: Steffen Klassert 
Date: Wed, 21 Oct 2015 08:57:04 +0200

> On Mon, Oct 19, 2015 at 05:23:29PM -0400, Sowmini Varadhan wrote:
>> On sparc, deleting established SAs (e.g., by restarting ipsec
>> at the peer) results in unaligned access messages via
>> xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify().
>> Use an aligned pointer to xfrm_usersa_info for this case.
>> 
>> Signed-off-by: Sowmini Varadhan 
>> ---
>>  net/xfrm/xfrm_user.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
>> index a8de9e3..158ef4a 100644
>> --- a/net/xfrm/xfrm_user.c
>> +++ b/net/xfrm/xfrm_user.c
>> @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const 
>> struct km_event *c)
>>  if (attr == NULL)
>>  goto out_free_skb;
>>  
>> -p = nla_data(attr);
>> +p = PTR_ALIGN(nla_data(attr), __alignof__(*p));
> 
> Hm, this breaks userspace notifications on 64-bit systems.
> Userspace expects this to be aligned to 4, with your patch
> it is aligned to 8 on 64-bit.

That's correct, netlink attributes are fundamentally only 4 byte
aligned and this cannot be changed.  nla_data() is exactly
where the attribute must be placed, aligned or not.

The only workaround is, when designing netlink attributes.  Various
netlink libraries have workarounds for accessing, for example, 64-bit
stats which are going to be unaligned in netlink messages.
--
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 net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

[David Miller]

From: Sowmini Varadhan 
Date: Wed, 21 Oct 2015 06:54:42 -0400

> On (10/21/15 08:57), Steffen Klassert wrote:
>> > --- a/net/xfrm/xfrm_user.c
>> > +++ b/net/xfrm/xfrm_user.c
>> > @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, 
>> > const struct km_event *c)
>> >if (attr == NULL)
>> >goto out_free_skb;
>> >  
>> > -  p = nla_data(attr);
>> > +  p = PTR_ALIGN(nla_data(attr), __alignof__(*p));
>> 
>> Hm, this breaks userspace notifications on 64-bit systems.
>> Userspace expects this to be aligned to 4, with your patch
>> it is aligned to 8 on 64-bit.
>> 
>> Without your patch I get the correct notification when deleting a SA:
>> 
> 
> But __alignof__(*p) is 8 on sparc, and without the patch I get
> all types of unaligned access. So what do you suggest as the fix?

The accesses have to be done using something like get_unaligned() and
put_unaligned().

Sorry, but the protocol is set in stone and this is unfortunately how
it is.
--
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: unaligned access in pkcs7_verify

[David Miller]

From: Herbert Xu 
Date: Mon, 12 Oct 2015 21:32:09 +0800

> The sparc sha algorithms themselves need to declare the alignment
> that they require.  Currently they claim to be able to handle any
> alignment which appears to not be the case.

The sparc SHA assembler can handle arbitrary alignment.
--
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 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256

[David Miller]

From: Tim Chen 
Date: Fri, 11 Sep 2015 11:49:32 -0700

> Still, why would some kernel module specifically not want to 
> use the fastest HW implementation, and explicitly ask for
> a slower driver?

Temporary workaround if a bug is found.

There is really no reason to prevent the user from having this
flexibility, and in return anyone can test any implementation
their cpu can support.
--
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 0/4] crypto: [sha] x86 SHA extension optimization of SHA1 and SHA256

[David Miller]

From: Tim Chen 
Date: Thu, 10 Sep 2015 15:26:52 -0700

> 
> The new x86 SHA extensions provide new hardware accelerated instructions
> for computing SHA1 and SHA256 hashes. This patch series provide the
> assembly routines for SHA1 and SHA256 computation using these new
> instructions to the kernel crypto library.  For 4K data blocks, we've
> seen up to 3.6x speedup over existing SSSE3 enhanced routines in the
> kernel crypto library on Broxton platform.
> 
> Refer to SHA extension programming guide in chapter 8.2 of the
> Intel Architecture Instruction Set Extensions Programming reference.
> https://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf
> 
> Pre-req patches:
> [1] [PATCH] sha: Enable cpuid check for Intel SHA extensions implementations
> http://marc.info/?l=linux-kernel=144019424304089=2
> [2] [Patch] x86/insn: perf tools: Add new SHA instructions
> http://marc.info/?l=linux-kernel=144119645000679=2

Series looks fine to me:

Acked-by: David S. Miller 
--
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 0/7] crypto: Convert all AEAD users to new interface

[David Miller]

From: Herbert Xu herb...@gondor.apana.org.au
Date: Thu, 21 May 2015 18:39:39 +0800

 This series of patches convert all in-tree AEAD users that I
 could find to the new single SG list interface.  For IPsec it
 also adopts the new explicit IV generator scheme.

No objections on my end.

I assume since the dependencies exist in the crypto tree, you'll
want to merge this series there right?
--
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 0/6] crypto: Make all AEAD users include aead.h

[David Miller]

From: Herbert Xu herb...@gondor.apana.org.au
Date: Wed, 22 Apr 2015 15:04:55 +0800

 This series adds inclusions of aead.h to all AEAD users including
 AEAD implementors (where it's internal/aead.h).  This is necessary
 because I'll be adding an updated AEAD interface and that will live
 in aead.h instead of crypto.h.
 
 Dave, if it's OK with you I'd like to push the last two patches
 through my tree as the new AEAD interface would depend on them.

No objection, feel free to add my:

Acked-by: David S. Miller da...@davemloft.net
--
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: CCM/GCM implementation defect

[David Miller]

From: Herbert Xu herb...@gondor.apana.org.au
Date: Thu, 23 Apr 2015 11:26:20 +0800

 In order to fix this without breaking backwards compatibility,
 my plan is to introduce new templates such as rfc4106v2 which
 implement the RFC correctly.  The existing templates will be
 retained so that current users aren't broken by the fix.
 
 Once the kernel side is complete we could then get the user-space
 implementors to update their tools to request for the new v2
 templates.
 
 Comments?

At first glance this seems like a very reasonable approach.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: Fix aead_{sendmsg,recvmsg}() signatures.

[David Miller]

The kiocb argument is no longer present.

Signed-off-by: David S. Miller da...@davemloft.net

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 527d27b..95ad689 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -163,8 +163,7 @@ static void aead_data_wakeup(struct sock *sk)
rcu_read_unlock();
 }
 
-static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
-   struct msghdr *msg, size_t size)
+static int aead_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
 {
struct sock *sk = sock-sk;
struct alg_sock *ask = alg_sk(sk);
@@ -348,8 +347,8 @@ unlock:
return err ?: size;
 }
 
-static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
-   struct msghdr *msg, size_t ignored, int flags)
+static int aead_recvmsg(struct socket *sock, struct msghdr *msg,
+   size_t ignored, int flags)
 {
struct sock *sk = sock-sk;
struct alg_sock *ask = alg_sk(sk);
--
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: Fix aead_{sendmsg,recvmsg}() signatures.

[David Miller]

From: Herbert Xu herb...@gondor.apana.org.au
Date: Sat, 18 Apr 2015 09:33:17 +0800

 On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote:
 
 The kiocb argument is no longer present.
 
 Signed-off-by: David S. Miller da...@davemloft.net
 
 I think Linus has already fixed this with
 
 commit eccd02f32a2c25139da2d5e72ebab1fee7b5baab
 Author: Linus Torvalds torva...@linux-foundation.org
 Date:   Wed Apr 15 14:09:46 2015 -0700
 
 crypto: fix mis-merge with the networking merge

Awesome, thanks Herbert.
--
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 net-next] crypto: algif - explicitly mark end of data

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Wed, 01 Apr 2015 13:53:06 -0700

 After the TX sgl is expanded we need to explicitly mark end of data
 at the last buffer that contains data.
 
 Changes in v2
  - use type 'bool' and true/false for 'mark'.
 
 Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com

Applied.
--
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 net-next] crypto: af_alg - make exports consistant

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Mon, 30 Mar 2015 14:25:43 -0700

 Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
 
 Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com

Applied.
--
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 net-next] crypto: algif - use kmalloc instead of kzalloc

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Mon, 30 Mar 2015 14:25:44 -0700

 No need to use kzalloc to allocate sgls as the structure is initialized 
 anyway.
 
 Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com

Applied.
--
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 net-next] crypto: algif - explicitly mark end of data

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Mon, 30 Mar 2015 14:25:43 -0700

 + int mark = 0, err = -ENOMEM;
  
   lock_sock(sk);
   req = kmalloc(reqlen, GFP_KERNEL);
 ...
 @@ -573,10 +572,11 @@ static int skcipher_recvmsg_async(struct socket *sock, 
 struct msghdr *msg,
   kfree(sreq-tsg);
   sreq-tsg = tmp;
   tx_nents *= 2;
 + mark = 1;
 ...
 @@ -604,6 +604,9 @@ static int skcipher_recvmsg_async(struct socket *sock, 
 struct msghdr *msg,
   iov_iter_advance(msg-msg_iter, used);
   }
  
 + if (mark)
 + sg_mark_end(sreq-tsg + txbufs - 1);

Please use type 'bool' and true/false for 'mark'.
--
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 net-next] crypto: algif - fix warn: unsigned 'used' is never less than zero

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Wed, 25 Mar 2015 07:29:19 -0700

 Change type from unsigned long to int to fix an issue reported by kbuild 
 robot:
 crypto/algif_skcipher.c:596 skcipher_recvmsg_async() warn: unsigned 'used' is
 never less than zero.
 
 Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com

Applied.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 net-next 0/3] Add support for async socket operations

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Thu, 19 Mar 2015 12:31:19 -0700

 After the iocb parameter has been removed from sendmsg() and recvmsg() ops
 the socket layer, and the network stack no longer support async operations.
 This patch set adds support for asynchronous operations on sockets back.
 
 Changes in v3:
 * As sugested by Al Viro instead of adding new functions aio_sendmsg
   and aio_recvmsg, added a ptr to iocb into the kernel-side msghdr structure.
   This way no change to aio.c is required.
 
 Changes in v2:
 * removed redundant total_size param from aio_sendmsg and aio_recvmsg 
 functions

Series applied to net-next.
--
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 net-next 0/4] Add support for async socket operations

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Wed, 18 Mar 2015 13:59:30 -0700

 What's your take on this patch set?

I'm really busy so waiting for Al to give some feedback first.
--
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/4] net: esp: check CRYPTO_TFM_REQ_DMA flag when allocating crypto request

[David Miller]

From: Horia Geantă horia.gea...@freescale.com
Date: Sat, 14 Mar 2015 14:16:37 +0200

 However, ESP is not using aead_request_alloc().

Then find a way to adjust it to do so.
--
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/4] net: esp: check CRYPTO_TFM_REQ_DMA flag when allocating crypto request

[David Miller]

From: Horia Geanta horia.gea...@freescale.com
Date: Fri, 13 Mar 2015 19:15:22 +0200

 Some crypto backends might require the requests' private contexts
 to be allocated in DMA-able memory.
 
 Signed-off-by: Horia Geanta horia.gea...@freescale.com

No way.

Upper layers should be absolutely not required to know about such
requirements.

Such details _must_ be hidden inside of the crypto layer and drivers
and not leak out into the users of the crypto interfaces.
--
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] mm: kill kmemcheck

[David Miller]

From: Sasha Levin sasha.le...@oracle.com
Date: Wed, 11 Mar 2015 09:39:33 -0400

 On 03/11/2015 08:40 AM, Steven Rostedt wrote:
 On Wed, 11 Mar 2015 08:34:46 -0400
 Sasha Levin sasha.le...@oracle.com wrote:
 
  Fair enough. We knew there are existing kmemcheck users, but KASan should 
  be
  superior both in performance and the scope of bugs it finds. It also 
  shouldn't
  impose new limitations beyond requiring gcc 4.9.2+.
 
 Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3.
 
 It will be a while before I upgrade my build farm to something newer.
 
 Are you actually compiling new kernels with 4.6.3, or are you using older
 kernels as well?
 
 There's no real hurry to kill kmemcheck right now, but we do want to stop
 supporting that in favour of KASan.

Is the spectrum of CPU's supported by this GCC feature equal to all of the
CPU's supported by the kernel right now?

If not, removing kmemcheck will always be a regression for someone.
--
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] mm: kill kmemcheck

[David Miller]

From: Andrey Ryabinin ryabinin@gmail.com
Date: Wed, 11 Mar 2015 23:01:00 +0300

 2015-03-11 21:44 GMT+03:00 David Miller da...@davemloft.net:
 From: Sasha Levin sasha.le...@oracle.com
 Date: Wed, 11 Mar 2015 13:25:47 -0400

 You're probably wondering why there are changes to SPARC in that patchset? 
 :)

 Libsanitizer doesn't even build have the time on sparc, the release
 manager has to hand patch it into building again every major release
 because of the way ASAN development is done out of tree and local
 commits to the gcc tree are basically written over during the
 next merge.

 
 Libsanitizer is userspace lib it's for userspace ASan, KASan doesn't use it.
 We have our own 'libsanitzer' in kernel.

I was speaking about ASAN development in general, of which the
libsanitizer issue is a byproduct.
--
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] mm: kill kmemcheck

[David Miller]

From: Sasha Levin sasha.le...@oracle.com
Date: Wed, 11 Mar 2015 13:25:47 -0400

 You're probably wondering why there are changes to SPARC in that patchset? :)

Libsanitizer doesn't even build have the time on sparc, the release
manager has to hand patch it into building again every major release
because of the way ASAN development is done out of tree and local
commits to the gcc tree are basically written over during the
next merge.

So I'm a little bit bitter about this, as you can see. :)
--
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: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

From: Tadeusz Struk tadeusz.st...@intel.com
Date: Tue, 10 Mar 2015 20:25:29 -0700

 In my opinion this is not about a single, special case, but rather
 about being able to support asynchronous operations on socket
 interface.

Nobody used the socket AIO facility for two decades, it just
rotted and turned out to be buggy and reference freed stack
memory on top of that.

I am absolutely not convinced this is the only way to solve your
problem.
--
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: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

From: Ying Xue ying@windriver.com
Date: Wed, 11 Mar 2015 11:18:01 +0800

 Sorry, I did not realize the case when I created the commit. However, 
 although I
 don't understand its scenario, in my opinion, adding one redundant argument 
 for
 all sockets to satisfy the special case seems unreasonable for us.

And the AIO socket mechanism was buggy and references freed up stack
objects.

That whole set of problems would need to be addressed fully before
we could even think of adding AIO support back to the socket layer.
--
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: net: Remove iocb argument from sendmsg and recvmsg

[David Miller]

Because of the way you quoted the patch, it looked like a list posting
looping back to the list again, because of the List-ID:  email header.

Therefore your posting was blocked and you'll have to resend your posting
in a way such that this doesn't happen.
--
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 4/6] crypto: sparc64/des - add des3_ede module alias

[David Miller]

From: Mathias Krause mini...@googlemail.com
Date: Sun, 11 Jan 2015 18:17:45 +0100

 This module provides implementations for des3_ede, too. Announce those
 via an appropriate crypto module alias so it can be used in favour to
 the generic C implementation.
 
 Cc: David S. Miller da...@davemloft.net
 Signed-off-by: Mathias Krause mini...@googlemail.com

Acked-by: David S. Miller da...@davemloft.net
--
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/6] crypto: sparc64/aes - fix module description

[David Miller]

From: Mathias Krause mini...@googlemail.com
Date: Sun, 11 Jan 2015 18:17:43 +0100

 AES is a block cipher, not a hash.
 
 Cc: David S. Miller da...@davemloft.net
 Signed-off-by: Mathias Krause mini...@googlemail.com

Acked-by: David S. Miller da...@davemloft.net
--
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 3/6] crypto: sparc64/camellia - fix module alias

[David Miller]

From: Mathias Krause mini...@googlemail.com
Date: Sun, 11 Jan 2015 18:17:44 +0100

 The module alias should be camellia, not aes.
 
 Cc: David S. Miller da...@davemloft.net
 Signed-off-by: Mathias Krause mini...@googlemail.com

Acked-by: David S. Miller da...@davemloft.net
--
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 5/6] crypto: sparc64/md5 - fix module description

[David Miller]

From: Mathias Krause mini...@googlemail.com
Date: Sun, 11 Jan 2015 18:17:46 +0100

 MD5 is not SHA1.
 
 Cc: David S. Miller da...@davemloft.net
 Signed-off-by: Mathias Krause mini...@googlemail.com

Acked-by: David S. Miller da...@davemloft.net
--
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: Remove unnecessary KERN_INFO from testmgr.c

[David Miller]

From: Masanari Iida standby2...@gmail.com
Date: Tue,  7 Oct 2014 00:37:54 +0900

 This patch remove unncessary KERN_INFO from pr_info within testmgr.c
 
 Signed-off-by: Masanari Iida standby2...@gmail.com

Acked-by: David S. Miller da...@davemloft.net
--
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