Re: AIO operation and CMSG

[Stephan Mueller]

Am Mittwoch, 17. Januar 2018, 20:22:13 CET schrieb Christoph Hellwig:

Hi Christoph,

> On Sun, Jan 14, 2018 at 09:01:00AM +0100, Stephan Müller wrote:
> > The syscall io_submit sends data to the kernel and invokes the respective
> > handler function in the kernel such as the recvmsg handler. What I am
> > wondering is whether there is a way to send CMSG data along with the
> > io_submit syscall? If not, is CMSG handling with the AIO syscalls
> > possible at all?
> Not as-is, but it could be easily added by repurposing unused fields
> in the iocb.  The big question is if it should be done to the existing
> IOCB_CMD_PREADV/IOCB_CMD_PWRITEV types, or if new SENDMSG/RECVMSG ones
> should be added instead.

Thank you for the clarification. I think for the moment we have found another 
solution that we are discussing at linux-crypto. Therefore, I would currently 
not see the need for an additional support of CMSG in AIO.

Ciao
Stephan

Re: [PATCH v2] net/core: Increase default optmem_max limit

[Stephan Mueller]

Am Dienstag, 16. Januar 2018, 18:16:43 CET schrieb Björn 'besser82' Esser:

Hi Björn,

> With the new Linux Kernel Crypto API User Space Interface
> and its underlying AF_ALG socket, the current default value
> for `net.core.optmem_max` can be exhausted pretty quick when
> using asynchronous IO; on 32 bit systems it is not even enough
> for sending about 10 IOVECs at once to the socket interface.
> 
> To provide consumers of this new user space interface a well
> sufficient and reasonable maximum ancillary buffer size per
> socket by default, the limit is increased to four times of
> the previous setting:
> 
>   * 32 bit systems:  from 10240 bytes to 40960 bytes
>   * 64 bit systems:  from 20480 bytes to 81920 bytes
> 
> This allows for sending 32/64 (32/64 bit) parallel IOVECs at
> once to the socket interface, which should be enough for use
> in real world applications.
> 
> Signed-off-by: Björn Esser <besse...@fedoraproject.org>

Considering NR_FILE defining the default maximum number of file descriptors, 
at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I 
would assume to be ok in current systems.

Reviewed-by: Stephan Mueller <smuel...@chronox.de>

Ciao
Stephan

Re: [crypto 6/8] chtls: TCB and Key program

[Stephan Mueller]

Am Donnerstag, 7. Dezember 2017, 16:08:04 CET schrieb Atul Gupta:

Hi Atul,

> > As far as I see, the key is part of the skb (via kctx). This skb is
> > released after being processed. The release calls kfree_skb which does
> > not zeroize the key. Wouldn't it make sense to clear the memory of the
> > key when the skb is released? [Atul] we should perhaps memset the info
> > received from user so that driver has no info on key once its written on
> > chip memory. memset(gcm_ctx->key, 0, keylen);
> 
> Are you saying that the skb (via kctx) above does not obtain a copy of the
> key? If not, what is done in chtls_key_info? It does have a key copy, I was
> not sure how key info is accessed once skb is released.

All I am saying is that this key copy should be zapped when the memory is 
released. Thus, if the skb has a copy of the key, at least at the time of 
free() of the skb, a memset() of the key memory should be done (or before).
> 
> 
> Ciao
> Stephan
> 
> Thanks
> Atul



Ciao
Stephan

Re: [crypto 6/8] chtls: TCB and Key program

[Stephan Mueller]

Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta:

Hi Atul,

> 
> memzero_explicit(key)?
> [Atul] may not be required as entire info of size keylen and AEAD_H_SIZE is
> copied onto kctx->key. Key data is received from user, while ghash is
> memset and locally generated

Sure, but wouldn't it make sense to zap all instances where key material was 
stored?

> 
> As far as I see, the key is part of the skb (via kctx). This skb is released
> after being processed. The release calls kfree_skb which does not zeroize
> the key. Wouldn't it make sense to clear the memory of the key when the skb
> is released? [Atul] we should perhaps memset the info received from user so
> that driver has no info on key once its written on chip memory.
> memset(gcm_ctx->key, 0, keylen);

Are you saying that the skb (via kctx) above does not obtain a copy of the 
key? If not, what is done in chtls_key_info?


Ciao
Stephan

Re: [crypto 6/8] chtls: TCB and Key program

[Stephan Mueller]

Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta:

Hi Atul,

> program the tx and rx key on chip.
> 
> Signed-off-by: Atul Gupta 
> ---
>  drivers/crypto/chelsio/chtls/chtls_hw.c | 394
>  1 file changed, 394 insertions(+)
>  create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
> 
> diff --git a/drivers/crypto/chelsio/chtls/chtls_hw.c
> b/drivers/crypto/chelsio/chtls/chtls_hw.c new file mode 100644
> index 000..5e65aa2
> --- /dev/null
> +++ b/drivers/crypto/chelsio/chtls/chtls_hw.c
> @@ -0,0 +1,394 @@
> +/*
> + * Copyright (c) 2017 Chelsio Communications, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Written by: Atul Gupta (atul.gu...@chelsio.com)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "chtls.h"
> +#include "chtls_cm.h"
> +
> +static void __set_tcb_field_direct(struct chtls_sock *csk,
> +struct cpl_set_tcb_field *req, u16 word,
> +u64 mask, u64 val, u8 cookie, int no_reply)
> +{
> + struct ulptx_idata *sc;
> +
> + INIT_TP_WR_CPL(req, CPL_SET_TCB_FIELD, csk->tid);
> + req->wr.wr_mid |= htonl(FW_WR_FLOWID_V(csk->tid));
> + req->reply_ctrl = htons(NO_REPLY_V(no_reply) |
> + QUEUENO_V(csk->rss_qid));
> + req->word_cookie = htons(TCB_WORD(word) | TCB_COOKIE_V(cookie));
> + req->mask = cpu_to_be64(mask);
> + req->val = cpu_to_be64(val);
> + sc = (struct ulptx_idata *)(req + 1);
> + sc->cmd_more = htonl(ULPTX_CMD_V(ULP_TX_SC_NOOP));
> + sc->len = htonl(0);
> +}
> +
> +void __set_tcb_field(struct sock *sk, struct sk_buff *skb, u16 word,
> +  u64 mask, u64 val, u8 cookie, int no_reply)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> + struct cpl_set_tcb_field *req;
> + struct ulptx_idata *sc;
> + unsigned int wrlen = roundup(sizeof(*req) + sizeof(*sc), 16);
> +
> + req = (struct cpl_set_tcb_field *)__skb_put(skb, wrlen);
> + __set_tcb_field_direct(csk, req, word, mask, val, cookie, no_reply);
> + set_wr_txq(skb, CPL_PRIORITY_CONTROL, csk->port_id);
> +}
> +
> +static int chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64
> val) +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> + struct sk_buff *skb;
> + struct cpl_set_tcb_field *req;
> + struct ulptx_idata *sc;
> + unsigned int wrlen = roundup(sizeof(*req) + sizeof(*sc), 16);
> + unsigned int credits_needed = DIV_ROUND_UP(wrlen, 16);
> +
> + skb = alloc_skb(wrlen, GFP_ATOMIC);
> + if (!skb)
> + return -ENOMEM;
> +
> + __set_tcb_field(sk, skb, word, mask, val, 0, 1);
> + set_queue(skb, (csk->txq_idx << 1) | CPL_PRIORITY_DATA, sk);
> + csk->wr_credits -= credits_needed;
> + csk->wr_unacked += credits_needed;
> + enqueue_wr(csk, skb);
> + cxgb4_ofld_send(csk->egress_dev, skb);
> + return 0;
> +}
> +
> +/*
> + * Set one of the t_flags bits in the TCB.
> + */
> +int chtls_set_tcb_tflag(struct sock *sk, unsigned int bit_pos, int val)
> +{
> + return chtls_set_tcb_field(sk, 1, 1ULL << bit_pos,
> + val << bit_pos);
> +}
> +
> +static int chtls_set_tcb_keyid(struct sock *sk, int keyid)
> +{
> + return chtls_set_tcb_field(sk, 31, 0xULL, keyid);
> +}
> +
> +static int chtls_set_tcb_seqno(struct sock *sk)
> +{
> + return chtls_set_tcb_field(sk, 28, ~0ULL, 0);
> +}
> +
> +static int chtls_set_tcb_quiesce(struct sock *sk, int val)
> +{
> + return chtls_set_tcb_field(sk, 1, (1ULL << TF_RX_QUIESCE_S),
> +TF_RX_QUIESCE_V(val));
> +}
> +
> +static void *chtls_alloc_mem(unsigned long size)
> +{
> + void *p = kmalloc(size, GFP_KERNEL);
> +
> + if (!p)
> + p = vmalloc(size);
> + if (p)
> + memset(p, 0, size);
> + return p;
> +}
> +
> +static void chtls_free_mem(void *addr)
> +{
> + unsigned long p = (unsigned long)addr;
> +
> + if (p >= VMALLOC_START && p < VMALLOC_END)
> + vfree(addr);
> + else
> + kfree(addr);
> +}
> +
> +/* TLS Key bitmap processing */
> +int chtls_init_kmap(struct chtls_dev *cdev, struct cxgb4_lld_info *lldi)
> +{
> + unsigned int num_key_ctx, bsize;
> +
> + num_key_ctx = (lldi->vr->key.size / TLS_KEY_CONTEXT_SZ);
> + bsize = BITS_TO_LONGS(num_key_ctx);
> +
> + cdev->kmap.size = num_key_ctx;
> + cdev->kmap.available = bsize;
> + cdev->kmap.addr = chtls_alloc_mem(sizeof(*cdev->kmap.addr) *
> +   bsize);
> + if (!cdev->kmap.addr)
> + return -1;
> +
> + 

Re: [RFC PATCH 2/2] Crypto kernel tls socket

[Stephan Mueller]

Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu:

Hi Herbert,

>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote:
>> Userspace crypto interface for TLS.  Currently supports gcm(aes) 128bit
>> only, however the interface is the same as the rest of the SOCK_ALG
>> interface, so it should be possible to add more without any user interface
>> changes.
>
>SOCK_ALG exists to export crypto algorithms to user-space.  So if
>we decided to support TLS as an algorithm then I guess this makes
>sense.
>
>However, I must say that it wouldn't have been my first pick.  I'd
>imagine a TLS socket to look more like a TCP socket, or perhaps a
>KCM socket as proposed by Tom.

If I may ask: what is the benefit of having TLS in kernel space? I do not see 
any reason why higher-level protocols should be in the kernel as they do not 
relate to accessing hardware.

The only reason I could fathom is to keep the negotiated keys in a secure 
realm. But that could be done without having parts or the whole TLS protocol 
stack in the kernel. If the key management should stay in the kernel as a 
protection domain, I would rather think that the kernel should offer a plug-
and-play of raw ciphers where user space is responsible to form a protocol. 
This way, we do not limit such key management to TLS, but allow any kind of 
protocol to use it.

E.g. the kernel performs the key transport with RSA or key agreement with DH 
using keyring-based key material. The resulting shared secret is again 
maintained in the key ring where user space can use the symmetric ciphers of 
the kernel with those keys. User space would only see references to keys but 
no real keys. However, only user space knows when to invoke what cipher to 
implement a specific protocol.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 2/2] Crypto kernel tls socket

[Stephan Mueller]

Am Dienstag, 24. November 2015, 12:20:00 schrieb Hannes Frederic Sowa:

Hi Hannes,
>
>You could also keep the secret in a master process and talk to that via
>ipc.

I could not agree more.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 2/2] Crypto kernel tls socket

[Stephan Mueller]

Am Dienstag, 24. November 2015, 12:54:07 schrieb Phil Sutter:

Hi Phil,
>
>There "still" are dedicated crypto engines out there which need a driver
>to be accessed, so using them from userspace is not as simple as with
>padlock or AESNI. This was the reasoning behind the various cryptodev
>implementations and af_alg. Using those to establish a TLS connection
>with OpenSSL means to fetch encrypted data to userspace first and then
>feed it to the kernel again for decryption. Using cryptodev-linux, this
>will be zero-copy, but still there's an additional context switch
>involved which the approach here avoids.

Well, when being nasty, I could ask, why not putting the entire web server 
into the kernel. Heck, why not getting rid of user space?

Sorry, I could not resist. :-)

But back to the technical discussion. My main concern is that TLS is a big 
protocol and it is by far not the only crypto protocol where all those 
protocols seem to uses the same crypto primitives. And to me, there should be 
a good reason why software executes in supervisor state. Simply saving some 
context switches is not a good argument, because the context switches are 
there for a reason: to keep the system safe and secure.

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

Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

[Stephan Mueller]

Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg:

Hi Johannes,


IOW, I think something like this would make sense:


That looks definitely cleaner :-)

Though, my main concern was just to ensure that the aad length value is not 
zero.


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

Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

[Stephan Mueller]

Am Donnerstag, 21. Mai 2015, 13:20:49 schrieb Johannes Berg:

Hi Johannes,

 On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
  This patch makes use of the new AEAD interface which uses a single
  SG list instead of separate lists for the AD and plain text.
 
 Looks fine - want me to run any tests on it?

Just a short question on ieee80211_aes_ccm_encrypt, ieee80211_aes_ccm_decrypt, 
ieee80211_aes_gcm_encrypt, ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can 
the aad parameter of these functions be zero?

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

Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

[Stephan Mueller]

Am Montag, 1. Juni 2015, 15:42:41 schrieb Johannes Berg:

Hi Johannes,

On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
 Just a short question on ieee80211_aes_ccm_encrypt,
 ieee80211_aes_ccm_decrypt, ieee80211_aes_gcm_encrypt,
 ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can the aad parameter of
 these functions be zero?

What do you mean by zero? The pointer itself can clearly never be
NULL.

Thanks for clarifying: indeed I mean the value of the pointer, not the pointer 
itself :-)

The contents, now, that's a more interesting question. I believe it can
never be all zeroes, since association request frames are not
encrypted/protected and thus at least one byte in here must be non-zero.
The MAC addresses are also very likely non-zero, but technically
00:00:00:00:00:00 is a valid MAC address I believe.

So, even when having a malicious AP, that value is never zero? The driver of 
the question is the following code in the patch set:

+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));

...

+   aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);

...

crypto_aead_encrypt(aead_req);


When I played around with the aead_request_set_crypt, I saw a crash in the 
scatterlist handling of the crypto API when the first SGL entry has a zero 
length.

Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Freitag, 22. Mai 2015, 15:19:23 schrieb Herbert Xu:

Hi Herbert,

 On Fri, May 22, 2015 at 09:16:08AM +0200, Stephan Mueller wrote:
  Thanks for the pointer, but there I do not really see the functionality I
  am looking for. I see patch 10/16 which seems to indicate that the geniv
  logic is now to be invoked as a normal AEAD cipher. I yet fail to see
  where the distinction is made in the code that an IV is to be generated
  versus the given IV is to be used.
 
 Only IV generators algorithms will generate IV.  The generated IV
 will be placed at the start of cipher text.  See patches 14-16 for
 the actual implementation.

Thanks for the help.

May I also ask where I can find the generated IV when using rfc4106(gcm(aes))? 
The old invocation used aead_givcrypt_set_crypt(req, iv-data, 0) which 
delivered the 64 bit value generated by seqiv.

With the new invocation, I use the SGL with AD || IV space || PT

ivlen = crypto_aead_ivsize(tfm);
sg_init_table(sg, 3);
sg_set_buf(sg[0], aead_assoc-data, aead_assoc-len);
/* iv-data should be filled by seqiv */
sg_set_buf(sg[1], iv-data, ivlen);
sg_set_buf(sg[2], data-data, data-len +
   (enc ? authsize : 0));
aead_request_set_ad(req, aead_assoc-len, 0);
aead_request_set_crypt(req, sg, sg, data-len + ivlen, iv-data);

But in iv-data, there is nothing to be found after performing the encrypt 
operation.

Thanks a lot.

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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 14:24:33 schrieb Herbert Xu:

Hi Herbert,

 On Mon, May 25, 2015 at 07:53:41PM +0800, Herbert Xu wrote:
  On Mon, May 25, 2015 at 01:50:55PM +0200, Stephan Mueller wrote:
   When you have my code local, simply execute libkcapi/test/kcapi -y twice
   or
   three times. That triggered the crash.
  
  Aha that's what I was missing.  I'll look into the crash.
 
 OK I forgot to initialise the SG list.  This patch fixes it for me.

Confirmed. I see no more issues on the AF_ALG side.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 15:21:52 schrieb Herbert Xu:

Hi Herbert,

On Tue, May 26, 2015 at 08:39:56AM +0200, Stephan Mueller wrote:
 May I also ask where I can find the generated IV when using
 rfc4106(gcm(aes))?
You need to use the IV generator, seqniv(rfc4106(gcm(aes)))

Thank you, that simple change does the trick.

However, now, may I ask you how the following shall be handled:

- the current IKE implementations use rfc4106(gcm(aes)). They would need to 
use seqniv(rfc4106(gcm(aes))) depending on the kernel version. So, we have a 
clear change in the user space API where the old configuration even works 
(i.e. no error), but does not produce the correct encryption that is required.

- For outbound encryption of IPSEC, we need seqniv() as the IV needs to be 
generated. But for inbound, we do not need seqniv() as the IV is already given 
(before the patch, only esp_output used the givcrypt API whereas esp_input 
used the normal AEAD API). I would be interested on how that difference is 
to be handled.

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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 15:36:05 schrieb Herbert Xu:

Hi Herbert,

In order to allow this to be done I'm going to disable the AEAD
user-space interface in 4.1 so that we have time to fix it properly
for 4.2.

Ok. Would you look into that one or shall I do that?

Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 08:39:56 schrieb Stephan Mueller:

Hi,

Am Freitag, 22. Mai 2015, 15:19:23 schrieb Herbert Xu:

Hi Herbert,

 On Fri, May 22, 2015 at 09:16:08AM +0200, Stephan Mueller wrote:
  Thanks for the pointer, but there I do not really see the functionality I
  am looking for. I see patch 10/16 which seems to indicate that the geniv
  logic is now to be invoked as a normal AEAD cipher. I yet fail to see
  where the distinction is made in the code that an IV is to be generated
  versus the given IV is to be used.
 
 Only IV generators algorithms will generate IV.  The generated IV
 will be placed at the start of cipher text.  See patches 14-16 for
 the actual implementation.

Thanks for the help.

May I also ask where I can find the generated IV when using
rfc4106(gcm(aes))? The old invocation used aead_givcrypt_set_crypt(req,
iv-data, 0) which delivered the 64 bit value generated by seqiv.

With the new invocation, I use the SGL with AD || IV space || PT

   ivlen = crypto_aead_ivsize(tfm);
   sg_init_table(sg, 3);
   sg_set_buf(sg[0], aead_assoc-data, aead_assoc-len);
   /* iv-data should be filled by seqiv */
   sg_set_buf(sg[1], iv-data, ivlen);
   sg_set_buf(sg[2], data-data, data-len +
  (enc ? authsize : 0));
   aead_request_set_ad(req, aead_assoc-len, 0);
   aead_request_set_crypt(req, sg, sg, data-len + ivlen, iv-data);

But in iv-data, there is nothing to be found after performing the encrypt
operation.

To be more precise, in iv-data, there is some data. But it is always static 
(seqiv's uses a random number) and does not seem to be the IV used for GCM 
when checking with a reference implementation.

Thanks a lot.


Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 15:38:59 schrieb Herbert Xu:

Hi Herbert,

On Tue, May 26, 2015 at 09:37:09AM +0200, Stephan Mueller wrote:
 - the current IKE implementations use rfc4106(gcm(aes)). They would need to
 use seqniv(rfc4106(gcm(aes))) depending on the kernel version. So, we have
 a
 clear change in the user space API where the old configuration even works
 (i.e. no error), but does not produce the correct encryption that is
 required.
You mean through the user-space AEAD interface? That's not a problem
because I'm going to disable it for 4.1 :)

Actually, I mean the real in-kernel crypto API: the IKE daemon would set up 
the SA via XFRM where the rfc4106(gcm(aes)) cipher is set, is it not? So, user 
space is responsible to set the right IPSEC cipher.

As that user space cipher name is now changed, user space would need to be 
aware of that modification, would it not?

PS: I just tried seqniv(rfc4106(gcm(aes))) via AF_ALG and it works without 
crashing the kernel. I have not yet checked whether the data returned by 
recvmsg is cryptographically sound.

Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 16:18:01 schrieb Herbert Xu:

Hi Herbert,


This is all in the patch series that you're responding.  So please
actually read it rather than making assumptions :)

Sorry, you are right -- I overlooked the xfrm_algo_desc change. Thanks for 
helping.

Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Dienstag, 26. Mai 2015, 15:57:59 schrieb Herbert Xu:

Hi Herbert,

On Tue, May 26, 2015 at 09:56:17AM +0200, Stephan Mueller wrote:
 Actually, I mean the real in-kernel crypto API: the IKE daemon would set up
 the SA via XFRM where the rfc4106(gcm(aes)) cipher is set, is it not? So,
 user space is responsible to set the right IPSEC cipher.
 
 As that user space cipher name is now changed, user space would need to be
 aware of that modification, would it not?

No the change was done in a backwards compatible way.  So if you
allocate rfc4106(gcm(aes)) and use the givencrypt interface (not
encrypt) then you still get the old behaviour.

I fully understand that. But the current patch set that we discuss modifies 
the IPSEC implementation of esp_ouput to use the new interface. Therefore, to 
use rfc4106(gcm(aes)) *with* the IV generator (i.e. to get the old removed 
givcrypt logic), the AEAD cipher handle must be allocated with 
seqniv(rfc4106(gcm(aes))), would it not?

Therfore, I would assume that user space has to use the new cipher name when 
setting up IPSEC that uses the new interface.

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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Montag, 25. Mai 2015, 18:20:21 schrieb Herbert Xu:

Hi Herbert,

 On Sun, May 24, 2015 at 12:52:02PM +0200, Stephan Mueller wrote:
  [   29.653113] BUG: unable to handle kernel NULL pointer dereference at
  000c
 
 Weird.  I tried running your test but it appears to pass.  The only
 failures were the nonsense strings and everything else says pased.

To simply verify that all passes is to check for the return code: the return 
code tells you the number of failures --- the value of 0 indicates that all 
pass.

And I see a simple test problem: I added a debug return that I forgot to 
remove in the test.sh. Thus, the large test is not executed with test.sh.

When you have my code local, simply execute libkcapi/test/kcapi -y twice or 
three times. That triggered the crash.
 
 It certainly didn't crash for me.
 
 Considering that I just killed cryptoff in my local tree, it is
 entirely possible that the patches that you are running are no
 longer the same as mine.
 
 So let me merge the cryptoff patches and then I'll repost the
 algif_aead patch and ask you to retest.
 
 Thanks,


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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Sonntag, 24. Mai 2015, 11:34:20 schrieb Herbert Xu:

Hi Herbert,

 On Sat, May 23, 2015 at 08:04:19PM +0200, Stephan Mueller wrote:
  Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
  
  Hi Herbert,
  
   This patch makes use of the new AEAD interface which uses a single
   SG list instead of separate lists for the AD and plain text.
  
  After applying your additional patch, the normal AEAD operation works.
  
  But with long messages (16 filled pages), I get the following. To test,
  simply use [1], cd libkcapi/test, compile and execute ./kcapi -y
 
 Thanks for testing!
 
 Does this patch help?

Yes and no. Executing the test with 16 pages once passes. Executing it again 
(same test, same vectors) causes:

[   29.653113] BUG: unable to handle kernel NULL pointer dereference at 
000c
[   29.653118] IP: [812b6d78] scatterwalk_ffwd+0x28/0xd0
[   29.653123] PGD 7b775067 PUD 7b699067 PMD 0 
[   29.653125] Oops:  [#1] SMP 
[   29.653128] Modules linked in: crypto_user ccm algif_aead af_alg 
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack cfg80211 ebtable_nat ebtable_broute 
bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security 
iptable_raw crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel aes_x86_64 glue_helper ablk_helper virtio_balloon microcode joydev 
pcspkr serio_raw i2c_piix4 acpi_cpufreq virtio_net virtio_blk qxl 
drm_kms_helper ttm drm virtio_pci virtio_ring virtio
[   29.653151] CPU: 1 PID: 1759 Comm: kcapi Not tainted 4.0.0+ #220
[   29.653153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140709_153950- 04/01/2014
[   29.653154] task: 88007b798880 ti: 88007a434000 task.ti: 
88007a434000
[   29.653156] RIP: 0010:[812b6d78]  [812b6d78] 
scatterwalk_ffwd+0x28/0xd0
[   29.653158] RSP: 0018:88007a437a98  EFLAGS: 00010202
[   29.653160] RAX:  RBX: 6fe0 RCX: 
ea0001eef580
[   29.653161] RDX: 1000 RSI: 88007a437b38 RDI: 
88007a437c18
[   29.653162] RBP: 88007a437aa8 R08:  R09: 
88007a437cf8
[   29.653163] R10:  R11:  R12: 
88007b1fed90
[   29.653164] R13: 88007c0d7ac0 R14: 88007b1fed50 R15: 
88007b1fc000
[   29.653165] FS:  7fb3d7ace700() GS:88007fd0() 
knlGS:
[   29.653167] CS:  0010 DS:  ES:  CR0: 80050033
[   29.653168] CR2: 000c CR3: 7b779000 CR4: 
000407e0
[   29.653171] Stack:
[   29.653172]  88007b1fecf0 a02a0380 88007a437ad8 
812b7b40
[   29.653175]  88007b1fecb0 88007a437cf8  
8800798bf400
[   29.653177]  88007a437ae8 812b7c0d 88007a437d88 
a029a246
[   29.653179] Call Trace:
[   29.653182]  [a02a0380] ? crypto_ccm_decrypt+0x350/0x350 [ccm]
[   29.653185]  [812b7b40] old_crypt+0x50/0xe0
[   29.653187]  [812b7c0d] old_encrypt+0x1d/0x20
[   29.653189]  [a029a246] aead_recvmsg+0x6f6/0x860 [algif_aead]
[   29.653192]  [8114a672] ? __alloc_pages_nodemask+0x1a2/0x9d0
[   29.653195]  [81687b7a] ? _raw_spin_unlock_bh+0x1a/0x20
[   29.653197]  [a0299849] ? aead_sendmsg+0x429/0x4c0 [algif_aead]
[   29.653201]  [81561528] sock_recvmsg+0x38/0x50
[   29.653203]  [815615c8] sock_read_iter+0x88/0xd0
[   29.653205]  [811a9990] __vfs_read+0x90/0xc0
[   29.653207]  [811aa12a] vfs_read+0x8a/0x140
[   29.653209]  [811aab56] SyS_read+0x46/0xb0
[   29.653210]  [8168812e] system_call_fastpath+0x12/0x71
[   29.653211] Code: 0f 1f 00 66 66 66 66 90 55 85 d2 48 89 f0 48 89 e5 41 54 
53 89 d3 74 28 8b 56 0c 49 89 fc 39 d3 73 10 eb 27 0f 1f 80 00 00 00 00 8b 
50 0c 39 da 77 19 29 d3 48 89 c7 e8 87 a9 05 00 85 db 75 eb 
[   29.653233] RIP  [812b6d78] scatterwalk_ffwd+0x28/0xd0
[   29.653235]  RSP 88007a437a98
[   29.653236] CR2: 000c
[   29.653238] ---[ end trace b579ecce490b2e88 ]---
-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:

Hi Herbert,

 This patch makes use of the new AEAD interface which uses a single
 SG list instead of separate lists for the AD and plain text.

After applying your additional patch, the normal AEAD operation works.

But with long messages (16 filled pages), I get the following. To test, simply 
use [1], cd libkcapi/test, compile and execute ./kcapi -y



[   59.441841] BUG: unable to handle kernel NULL pointer dereference at 
000c
[   59.441853] IP: [812b6d78] scatterwalk_ffwd+0x28/0xd0
[   59.441866] PGD 78ad6067 PUD 799f5067 PMD 0 
[   59.441874] Oops:  [#1] SMP 
[   59.441880] Modules linked in: ansi_cprng drbg algif_rng ccm gcm algif_aead 
algif_skcipher sha512_ssse3 sha512_generic mcryptd sha1_ssse3 sha1_generic 
crypto_user des3_ede_x86_64 des_generic cmac algif_hash af_alg 
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack cfg80211 ebtable_nat ebtable_broute 
bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security 
iptable_raw crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel aes_x86_64 glue_helper ablk_helper microcode joydev pcspkr 
serio_raw virtio_balloon i2c_piix4 acpi_cpufreq virtio_net qxl virtio_blk 
drm_kms_helper
[   59.441958]  ttm drm virtio_pci virtio_ring virtio
[   59.441970] CPU: 1 PID: 2338 Comm: kcapi Not tainted 4.0.0+ #220
[   59.441975] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140709_153950- 04/01/2014
[   59.441995] task: 88007aa1e600 ti: 880035998000 task.ti: 
880035998000
[   59.441999] RIP: 0010:[812b6d78]  [812b6d78] 
scatterwalk_ffwd+0x28/0xd0
[   59.442007] RSP: 0018:88003599ba98  EFLAGS: 00010202
[   59.442007] RAX:  RBX: 6fe0 RCX: 
ea0001eaa500
[   59.442007] RDX: 1000 RSI: 88003599bb38 RDI: 
88003599bc18
[   59.442007] RBP: 88003599baa8 R08: 88003599bcf8 R09: 

[   59.442007] R10:  R11: 1000 R12: 
88007b802d90
[   59.442007] R13: 88007b3f3c40 R14: 88007b802d50 R15: 
88007b80
[   59.442007] FS:  7f6cf9da6700() GS:88007fd0() 
knlGS:
[   59.442007] CS:  0010 DS:  ES:  CR0: 80050033
[   59.442007] CR2: 000c CR3: 799a6000 CR4: 
000407e0
[   59.442007] Stack:
[   59.442007]  88007b802cf0 a02f6380 88003599bad8 
812b7b40
[   59.442007]  88007b802cb0 88007b88  
88007aa04000
[   59.442007]  88003599bae8 812b7c0d 88003599bd88 
a02e5252
[   59.442007] Call Trace:
[   59.442007]  [a02f6380] ? crypto_ccm_decrypt+0x350/0x350 [ccm]
[   59.442007]  [812b7b40] old_crypt+0x50/0xe0
[   59.442007]  [812b7c0d] old_encrypt+0x1d/0x20
[   59.442007]  [a02e5252] aead_recvmsg+0x702/0x862 [algif_aead]
[   59.442007]  [8114a672] ? __alloc_pages_nodemask+0x1a2/0x9d0
[   59.442007]  [81687b7a] ? _raw_spin_unlock_bh+0x1a/0x20
[   59.442007]  [a02e4849] ? aead_sendmsg+0x429/0x4c0 [algif_aead]
[   59.442007]  [81561528] sock_recvmsg+0x38/0x50
[   59.442007]  [815615c8] sock_read_iter+0x88/0xd0
[   59.442007]  [811a9990] __vfs_read+0x90/0xc0
[   59.442007]  [811aa12a] vfs_read+0x8a/0x140
[   59.442007]  [811aab56] SyS_read+0x46/0xb0
[   59.442007]  [8168812e] system_call_fastpath+0x12/0x71
[   59.442007] Code: 0f 1f 00 66 66 66 66 90 55 85 d2 48 89 f0 48 89 e5 41 54 
53 89 d3 74 28 8b 56 0c 49 89 fc 39 d3 73 10 eb 27 0f 1f 80 00 00 00 00 8b 
50 0c 39 da 77 19 29 d3 48 89 c7 e8 87 a9 05 00 85 db 75 eb 
[   59.442007] RIP  [812b6d78] scatterwalk_ffwd+0x28/0xd0
[   59.442007]  RSP 88003599ba98
[   59.442007] CR2: 000c
[   59.442368] ---[ end trace 09389ca31f370515 ]---
-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Samstag, 23. Mai 2015, 05:58:18 schrieb Herbert Xu:

Hi Herbert,

 On Fri, May 22, 2015 at 11:04:39PM +0200, Stephan Mueller wrote:
  Note, gcm(aes) looks good. Only rfc4106(gcm(aes)) causes the crash.
 
 Actually it looks like the culprit hasn't been merged yet so I'll
 just respin the series.
 
 Anyway, this patch should fix your crash:

That fixes the rfc4106(gcm(aes)) issue. Thanks.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Freitag, 22. Mai 2015, 14:45:54 schrieb Herbert Xu:

Hi Herbert,

On Fri, May 22, 2015 at 08:40:25AM +0200, Stephan Mueller wrote:
 If I may ask, where in your initial patch set is now decided that the IV
 generator is used (i.e. so that the givcrypt API is not needed any more)?

Please see

https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg14270.html

Thanks for the pointer, but there I do not really see the functionality I am 
looking for. I see patch 10/16 which seems to indicate that the geniv logic is 
now to be invoked as a normal AEAD cipher. I yet fail to see where the 
distinction is made in the code that an IV is to be generated versus the given 
IV is to be used.


Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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/7] esp6: Switch to new AEAD interface

[Stephan Mueller]

Am Donnerstag, 21. Mai 2015, 18:44:03 schrieb Herbert Xu:

Hi Herbert,

-  aead_givcrypt_set_callback(req, 0, esp_output_done, skb);
-  aead_givcrypt_set_crypt(req, sg, sg, clen, iv);
-  aead_givcrypt_set_assoc(req, asg, assoclen);
-  aead_givcrypt_set_giv(req, esph-enc_data,
-XFRM_SKB_CB(skb)-seq.output.low);
+  aead_request_set_crypt(req, sg, sg, ivlen + clen, iv);
+  aead_request_set_ad(req, assoclen, 0);

If I may ask, where in your initial patch set is now decided that the IV 
generator is used (i.e. so that the givcrypt API is not needed any more)?

Do I understand it correctly that you want to retire the givcrypt API 
entirely?

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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:

Hi Herbert,

 This patch makes use of the new AEAD interface which uses a single
 SG list instead of separate lists for the AD and plain text.

Using an up-to date tree with the full set of patches of this patch set, I get 
the following oops.

It can easily be reproduced by using [1]: go to libkcapi/test/ and compile 
with make. Then execute ./test.sh

[1] http://www.chronox.de/libkcapi.html



[   22.680910] BUG: unable to handle kernel NULL pointer dereference at 
  
(null)
[   22.680915] IP: [  (null)]   (null)
[   22.680917] PGD 3c62e067 PUD 3b28e067 PMD 0 
[   22.680919] Oops: 0010 [#1] SMP 
[   22.680921] Modules linked in: seqiv ccm gcm crypto_null algif_aead 
algif_skcipher sha512_ssse3 sha512_generic mcryptd sha1_ssse3 sha1_generic 
crypto_user des3_ede_x86_64 des_generic algif_hash af_alg 
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack cfg80211 ebtable_nat ebtable_broute 
bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security 
iptable_raw crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
aesni_intel aes_x86_64 glue_helper ablk_helper joydev microcode virtio_console 
serio_raw virtio_balloon pcspkr i2c_piix4 acpi_cpufreq qxl drm_kms_helper ttm 
drm virtio_net
[   22.680948]  virtio_blk virtio_pci virtio_ring virtio
[   22.680952] CPU: 1 PID: 1889 Comm: kcapi Not tainted 4.0.0+ #122
[   22.680954] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   22.680955] task: 88003c08cc80 ti: 88003b30 task.ti: 
88003b30
[   22.680956] RIP: 0010:[]  [  (null)]   
(null)
[   22.680958] RSP: 0018:88003b303ce0  EFLAGS: 00010282
[   22.680959] RAX: a02f5080 RBX: a0138b20 RCX: 
0001
[   22.680960] RDX: 0001 RSI: a02f5368 RDI: 
88003b303cf8
[   22.680961] RBP: 88003b303d88 R08:  R09: 
eaecbd00
[   22.680962] R10: 810676b4 R11: 88003c275240 R12: 
88003b1ff200
[   22.680963] R13: fffe R14: a02f5080 R15: 
0203
[   22.680965] FS:  7fade1fe8700() GS:88003fd0() 
knlGS:
[   22.680966] CS:  0010 DS:  ES:  CR0: 80050033
[   22.680967] CR2:  CR3: 3bdc9000 CR4: 
000407e0
[   22.680971] Stack:
[   22.680973]  812b7e6d 0002000c0003 020f0203 
88003b303cec
[   22.680975]  88003b303d14  00010044812b49c4 
2d36303134636672
[   22.680977]  6e7365612d6d6367 0069  

[   22.680979] Call Trace:
[   22.680984]  [812b7e6d] ? crypto_nivaead_default+0x14d/0x1a0
[   22.680986]  [812b7f5a] crypto_lookup_aead+0x9a/0xf0
[   22.680989]  [812b4f33] crypto_alloc_tfm+0x63/0x130
[   22.680992]  [81193dd1] ? kmem_cache_alloc_trace+0x1f1/0x230
[   22.680994]  [812b7fc9] crypto_alloc_aead+0x19/0x20
[   22.680996]  [a02d638e] aead_bind+0xe/0x10 [algif_aead]
[   22.680999]  [a02848d0] alg_bind+0x60/0x130 [af_alg]
[   22.681003]  [81561f68] SYSC_bind+0xb8/0xf0
[   22.681003]  [811c7eb5] ? fd_install+0x25/0x30
[   22.681003]  [81562850] ? SyS_socket+0x90/0xd0
[   22.681003]  [8104a0f7] ? trace_do_page_fault+0x37/0xb0
[   22.681003]  [81562ade] SyS_bind+0xe/0x10
[   22.681003]  [81687f6e] system_call_fastpath+0x12/0x71
[   22.681003] Code:  Bad RIP value.
[   22.681003] RIP  [  (null)]   (null)
[   22.681003]  RSP 88003b303ce0
[   22.681003] CR2: 
[   22.681053] ---[ end trace c1a8ba963ebab541 ]---

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

Re: [v2 PATCH 13/13] crypto: algif_aead - Switch to new AEAD interface

[Stephan Mueller]

Am Freitag, 22. Mai 2015, 22:59:34 schrieb Stephan Mueller:

Hi Stephan,

 Am Freitag, 22. Mai 2015, 16:31:04 schrieb Herbert Xu:
 
 Hi Herbert,
 
  This patch makes use of the new AEAD interface which uses a single
  SG list instead of separate lists for the AD and plain text.
 
 Using an up-to date tree with the full set of patches of this patch set, I
 get the following oops.
 
 It can easily be reproduced by using [1]: go to libkcapi/test/ and compile
 with make. Then execute ./test.sh
 
 [1] http://www.chronox.de/libkcapi.html

Note, gcm(aes) looks good. Only rfc4106(gcm(aes)) causes the crash.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev 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

[Stephan Mueller]

Am Donnerstag, 21. Mai 2015, 18:39:39 schrieb Herbert Xu:

Hi Herbert,

Hi:

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.

To recap, the old AEAD interface takes an associated data (AD)
SG list in addition to the plain/cipher text SG list(s).  That
forces the underlying AEAD algorithm implementors to try to stitch
those two lists together where possible in order to maximise the
contiguous chunk of memory passed to the ICV/hash function.  Things
get even more hairy for IPsec as it has a third piece of memory,
the generated IV (giv) that needs to be hashed.  One look at the
nasty things authenc does for example is enough to make anyone
puke :)

In fact the interface is just getting in our way because for the
main user IPsec the data is naturally contiguous as the protocol
was designed with this in mind.

So the new AEAD interface gets rid of the separate AD SG list
and instead simply requires the AD to be at the head of the src
and dst SG lists.  There is further provision for optional space
between the AD and the plain/cipher text for ease of implementation.

Wouldn't algif_aead be also a candiate for the transition? The current 
implementation of aead_recvmsg() splits the one SGL it received from user 
space into two: one for AD and one for the ciphertext.

I would assume that this split now can be completely eliminated by removing 
the for loop in aead_recvmsg entirely.

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