Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1351264 > unrolled thread

linux-next: manual merge of the crypto tree with the net-next tree

Back to article view | Back to linux.kernel

Contents

  linux-next: manual merge of the crypto tree with the net-next tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-07 03:20 +0100
    Re: linux-next: manual merge of the crypto tree with the net-next tree David Howells <dhowells@redhat.com> - 2016-03-07 12:10 +0100
      Re: linux-next: manual merge of the crypto tree with the net-next  tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-08 07:00 +0100
        Re: linux-next: manual merge of the crypto tree with the net-next tree David Howells <dhowells@redhat.com> - 2016-03-08 17:50 +0100
          Re: linux-next: manual merge of the crypto tree with the net-next  tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-08 22:30 +0100

#1351264 — linux-next: manual merge of the crypto tree with the net-next tree

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  net/rxrpc/rxkad.c

between commit:

  0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")

from the net-next tree and commit:

  1afe593b4239 ("rxrpc: Use skcipher")

from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc net/rxrpc/rxkad.c
index 3106a0c4960b,0d96b48a6492..000000000000
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@@ -128,21 -128,23 +128,23 @@@ static void rxkad_prime_packet_security
  	token = conn->key->payload.data[0];
  	memcpy(&iv, token->kad->session_key, sizeof(iv));
  
- 	desc.tfm = conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
- 
 -	tmpbuf.x[0] = conn->epoch;
 -	tmpbuf.x[1] = conn->cid;
 +	tmpbuf.x[0] = htonl(conn->epoch);
 +	tmpbuf.x[1] = htonl(conn->cid);
  	tmpbuf.x[2] = 0;
  	tmpbuf.x[3] = htonl(conn->security_ix);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	memcpy(&conn->csum_iv, &tmpbuf.x[2], sizeof(conn->csum_iv));
 -	ASSERTCMP(conn->csum_iv.n[0], ==, tmpbuf.x[2]);
 +	ASSERTCMP((u32 __force)conn->csum_iv.n[0], ==, (u32 __force)tmpbuf.x[2]);
  
  	_leave("");
  }
@@@ -251,12 -267,12 +267,12 @@@ out
   * checksum an RxRPC packet header
   */
  static int rxkad_secure_packet(const struct rxrpc_call *call,
 -				struct sk_buff *skb,
 -				size_t data_size,
 -				void *sechdr)
 +			       struct sk_buff *skb,
 +			       size_t data_size,
 +			       void *sechdr)
  {
  	struct rxrpc_skb_priv *sp;
- 	struct blkcipher_desc desc;
+ 	SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
  	struct rxrpc_crypt iv;
  	struct scatterlist sg[2];
  	struct {
@@@ -280,15 -297,12 +296,12 @@@
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* calculate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = sp->hdr.callNumber;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(sp->hdr.callNumber);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
@@@ -513,25 -539,29 +536,28 @@@ static int rxkad_verify_packet(const st
  
  	/* continue encrypting from where we left off */
  	memcpy(&iv, call->conn->csum_iv.x, sizeof(iv));
- 	desc.tfm = call->conn->cipher;
- 	desc.info = iv.x;
- 	desc.flags = 0;
  
  	/* validate the security checksum */
 -	x = htonl(call->channel << (32 - RXRPC_CIDSHIFT));
 -	x |= sp->hdr.seq & cpu_to_be32(0x3fffffff);
 -	tmpbuf.x[0] = call->call_id;
 -	tmpbuf.x[1] = x;
 +	x = call->channel << (32 - RXRPC_CIDSHIFT);
 +	x |= sp->hdr.seq & 0x3fffffff;
 +	tmpbuf.x[0] = htonl(call->call_id);
 +	tmpbuf.x[1] = htonl(x);
  
  	sg_init_one(&sg[0], &tmpbuf, sizeof(tmpbuf));
  	sg_init_one(&sg[1], &tmpbuf, sizeof(tmpbuf));
- 	crypto_blkcipher_encrypt_iv(&desc, &sg[0], &sg[1], sizeof(tmpbuf));
+ 
+ 	skcipher_request_set_tfm(req, call->conn->cipher);
+ 	skcipher_request_set_callback(req, 0, NULL, NULL);
+ 	skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
+ 
+ 	crypto_skcipher_encrypt(req);
+ 	skcipher_request_zero(req);
  
  	y = ntohl(tmpbuf.x[1]);
 -	y = (y >> 16) & 0xffff;
 -	if (y == 0)
 -		y = 1; /* zero checksums are not permitted */
 +	cksum = (y >> 16) & 0xffff;
 +	if (cksum == 0)
 +		cksum = 1; /* zero checksums are not permitted */
  
 -	cksum = htons(y);
  	if (sp->hdr.cksum != cksum) {
  		*_abort_code = RXKADSEALEDINCON;
  		_leave(" = -EPROTO [csum failed]");

[toc] | [next] | [standalone]

#1351535

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the crypto tree got a conflict in:
> 
>   net/rxrpc/rxkad.c
> 
> between commit:
> 
>   0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")
> 
> from the net-next tree and commit:
> 
>   1afe593b4239 ("rxrpc: Use skcipher")
> 
> from the crypto tree.

What's the best way to deal with this?  Should I take Herbert's

	[PATCH 18/26] rxrpc: Use skcipher

patch into my rxrpc tree also and pass it on to Dave?

David

[toc] | [prev] | [next] | [standalone]

#1352649 — Re: linux-next: manual merge of the crypto tree with the net-next tree

Hi David,

On Mon, 07 Mar 2016 11:08:25 +0000 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Today's linux-next merge of the crypto tree got a conflict in:
> > 
> >   net/rxrpc/rxkad.c
> > 
> > between commit:
> > 
> >   0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in host byte order")
> > 
> > from the net-next tree and commit:
> > 
> >   1afe593b4239 ("rxrpc: Use skcipher")
> > 
> > from the crypto tree.  
> 
> What's the best way to deal with this?  Should I take Herbert's
> 
> 	[PATCH 18/26] rxrpc: Use skcipher
> 
> patch into my rxrpc tree also and pass it on to Dave?

Linus can deal with it when he merges the latter of the crypto or
net-next trees.  It might be worth a mention in the respective pull
requests.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1353207

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > What's the best way to deal with this?  Should I take Herbert's
> > 
> > 	[PATCH 18/26] rxrpc: Use skcipher
> > 
> > patch into my rxrpc tree also and pass it on to Dave?
> 
> Linus can deal with it when he merges the latter of the crypto or
> net-next trees.  It might be worth a mention in the respective pull
> requests.

Do you mean I should take it - or just let Linus merge it?

I tried to apply the rxrpc skcipher patch to net-next, but
skcipher_request_zero() isn't available there or in any of the patches in the
series.

David

[toc] | [prev] | [next] | [standalone]

#1353419 — Re: linux-next: manual merge of the crypto tree with the net-next tree

Hi David,

On Tue, 08 Mar 2016 16:48:07 +0000 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > What's the best way to deal with this?  Should I take Herbert's
> > > 
> > > 	[PATCH 18/26] rxrpc: Use skcipher
> > > 
> > > patch into my rxrpc tree also and pass it on to Dave?  
> > 
> > Linus can deal with it when he merges the latter of the crypto or
> > net-next trees.  It might be worth a mention in the respective pull
> > requests.  
> 
> Do you mean I should take it - or just let Linus merge it?

Just leave it to Linus.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web