Re: [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
On Tue, Dec 07, 2010 at 11:29:03AM +0100, Martin Willi wrote: Add TFC padding to all packets smaller than the boundary configured on the xfrm state. If the boundary is larger than the PMTU, limit padding to the PMTU. Thanks for the update Martin. However, I still think it's more complicated than it needs be. In particular, why would we need a boundary at all? Setting it to anything other than the PMTU would seem to defeat the purpose of TFC for packets between the boundary and the PMTU. If we can get rid of tfc.pad, we can simplify the user-interface change to just adding an xfrm_state flag. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
In particular, why would we need a boundary at all? Setting it to anything other than the PMTU would seem to defeat the purpose of TFC for packets between the boundary and the PMTU. I don't agree, this highly depends on the traffic on the SA. For a general purpose tunnel with TCP flows, PMTU padding is fine. But if there are only small packets (maybe SIP+RTP), padding to the PMTU is very expensive. The administrator setting up the SAs probably knows (or even controls directly) what traffic it is used for, and might lower the boundary accordingly. Regards Martin -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
On Wed, Dec 08, 2010 at 10:20:41AM +0100, Martin Willi wrote: In particular, why would we need a boundary at all? Setting it to anything other than the PMTU would seem to defeat the purpose of TFC for packets between the boundary and the PMTU. I don't agree, this highly depends on the traffic on the SA. For a general purpose tunnel with TCP flows, PMTU padding is fine. But if there are only small packets (maybe SIP+RTP), padding to the PMTU is very expensive. The administrator setting up the SAs probably knows (or even controls directly) what traffic it is used for, and might lower the boundary accordingly. OK, that's a good reason. But you should probably get rid of that unused flag field in the user-interface and just provide a pad length. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.5 5/5] keys: add new key-type encrypted
Mimi Zohar zo...@linux.vnet.ibm.com wrote: +static struct key *request_trusted_key(const char *trusted_desc, +u8 **master_key, +unsigned int *master_keylen) You need to annotate the function with an __acquires() to indicate that it returns with a lock held for Sparse checking. I think you should be able to do: __acquires(tkey-sem) hm, only after addding '__acquires' are there Sparse errors. Leave it, then. David -- 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 3/3] xfrm: Traffic Flow Confidentiality for IPv6 ESP
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi mar...@strongswan.org
---
net/ipv6/esp6.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index ee9b93b..1b5c982 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -49,6 +49,8 @@ struct esp_skb_cb {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)((__skb)-cb[0]))
+static u32 esp6_get_mtu(struct xfrm_state *x, int mtu);
+
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -140,6 +142,8 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff
*skb)
int blksize;
int clen;
int alen;
+ int plen;
+ int tfclen;
int nfrags;
u8 *iv;
u8 *tail;
@@ -148,18 +152,26 @@ static int esp6_output(struct xfrm_state *x, struct
sk_buff *skb)
/* skb is pure payload to encrypt */
err = -ENOMEM;
- /* Round to block size */
- clen = skb-len;
-
aead = esp-aead;
alen = crypto_aead_authsize(aead);
+ tfclen = 0;
+ if (x-tfcpad) {
+ struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
+ u32 padto;
+
+ padto = min(x-tfcpad, esp6_get_mtu(x, dst-child_mtu_cached));
+ if (skb-len padto)
+ tfclen = padto - skb-len;
+ }
blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- clen = ALIGN(clen + 2, blksize);
+ clen = ALIGN(skb-len + 2 + tfclen, blksize);
if (esp-padlen)
clen = ALIGN(clen, esp-padlen);
+ plen = clen - skb-len - tfclen;
- if ((err = skb_cow_data(skb, clen - skb-len + alen, trailer)) 0)
+ err = skb_cow_data(skb, tfclen + plen + alen, trailer);
+ if (err 0)
goto error;
nfrags = err;
@@ -174,13 +186,17 @@ static int esp6_output(struct xfrm_state *x, struct
sk_buff *skb)
/* Fill padding... */
tail = skb_tail_pointer(trailer);
+ if (tfclen) {
+ memset(tail, 0, tfclen);
+ tail += tfclen;
+ }
do {
int i;
- for (i=0; iclen-skb-len - 2; i++)
+ for (i = 0; i plen - 2; i++)
tail[i] = i + 1;
} while (0);
- tail[clen-skb-len - 2] = (clen - skb-len) - 2;
- tail[clen - skb-len - 1] = *skb_mac_header(skb);
+ tail[plen - 2] = plen - 2;
+ tail[plen - 1] = *skb_mac_header(skb);
pskb_put(skb, trailer, clen - skb-len + alen);
skb_push(skb, -skb_network_offset(skb));
--
1.7.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
[PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi mar...@strongswan.org
---
net/ipv4/esp4.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 14ca1f1..e42a905 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -23,6 +23,8 @@ struct esp_skb_cb {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)((__skb)-cb[0]))
+static u32 esp4_get_mtu(struct xfrm_state *x, int mtu);
+
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -117,25 +119,35 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
int blksize;
int clen;
int alen;
+ int plen;
+ int tfclen;
int nfrags;
/* skb is pure payload to encrypt */
err = -ENOMEM;
- /* Round to block size */
- clen = skb-len;
-
esp = x-data;
aead = esp-aead;
alen = crypto_aead_authsize(aead);
+ tfclen = 0;
+ if (x-tfcpad) {
+ struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
+ u32 padto;
+
+ padto = min(x-tfcpad, esp4_get_mtu(x, dst-child_mtu_cached));
+ if (skb-len padto)
+ tfclen = padto - skb-len;
+ }
blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- clen = ALIGN(clen + 2, blksize);
+ clen = ALIGN(skb-len + 2 + tfclen, blksize);
if (esp-padlen)
clen = ALIGN(clen, esp-padlen);
+ plen = clen - skb-len - tfclen;
- if ((err = skb_cow_data(skb, clen - skb-len + alen, trailer)) 0)
+ err = skb_cow_data(skb, tfclen + plen + alen, trailer);
+ if (err 0)
goto error;
nfrags = err;
@@ -150,13 +162,17 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
/* Fill padding... */
tail = skb_tail_pointer(trailer);
+ if (tfclen) {
+ memset(tail, 0, tfclen);
+ tail += tfclen;
+ }
do {
int i;
- for (i=0; iclen-skb-len - 2; i++)
+ for (i = 0; i plen - 2; i++)
tail[i] = i + 1;
} while (0);
- tail[clen - skb-len - 2] = (clen - skb-len) - 2;
- tail[clen - skb-len - 1] = *skb_mac_header(skb);
+ tail[plen - 2] = plen - 2;
+ tail[plen - 1] = *skb_mac_header(skb);
pskb_put(skb, trailer, clen - skb-len + alen);
skb_push(skb, -skb_network_offset(skb));
--
1.7.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
[PATCH 0/3] xfrm: ESP Traffic Flow Confidentiality padding (v3)
The following patchset adds Traffic Flow Confidentiality padding. The first patch introduces a new Netlink XFRM attribute to configure TFC via userspace. Patch two and three implement the padding logic in IPv4 and IPv6 ESP. Padding is always done using the RFC4303 format an is clamped to the PMTU. Changes from v2: - Remove unused flag field in attribute, use a plain u32 as attribute payload - Reject installation of TFC padding on non-tunnel SAs Martin Willi (3): xfrm: Add Traffic Flow Confidentiality padding XFRM attribute xfrm: Traffic Flow Confidentiality for IPv4 ESP xfrm: Traffic Flow Confidentiality for IPv6 ESP include/linux/xfrm.h |1 + include/net/xfrm.h |1 + net/ipv4/esp4.c | 32 net/ipv6/esp6.c | 32 net/xfrm/xfrm_user.c | 19 +-- 5 files changed, 67 insertions(+), 18 deletions(-) -- 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 1/3] xfrm: Add Traffic Flow Confidentiality padding XFRM attribute
The XFRMA_TFCPAD attribute for XFRM state installation configures
Traffic Flow Confidentiality by padding ESP packets to a specified
length.
Signed-off-by: Martin Willi mar...@strongswan.org
---
include/linux/xfrm.h |1 +
include/net/xfrm.h |1 +
net/xfrm/xfrm_user.c | 19 +--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index b971e38..930fdd2 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -283,6 +283,7 @@ enum xfrm_attr_type_t {
XFRMA_KMADDRESS,/* struct xfrm_user_kmaddress */
XFRMA_ALG_AUTH_TRUNC, /* struct xfrm_algo_auth */
XFRMA_MARK, /* struct xfrm_mark */
+ XFRMA_TFCPAD, /* __u32 */
__XFRMA_MAX
#define XFRMA_MAX (__XFRMA_MAX - 1)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index bcfb6b2..bdcade7 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -143,6 +143,7 @@ struct xfrm_state {
struct xfrm_id id;
struct xfrm_selectorsel;
struct xfrm_markmark;
+ u32 tfcpad;
u32 genid;
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 8bae6b2..8eb8895 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -148,7 +148,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
!attrs[XFRMA_ALG_AUTH_TRUNC]) ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
- attrs[XFRMA_ALG_COMP])
+ attrs[XFRMA_ALG_COMP] ||
+ attrs[XFRMA_TFCPAD])
goto out;
break;
@@ -165,6 +166,9 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_CRYPT])
attrs[XFRMA_ALG_AEAD])
goto out;
+ if (attrs[XFRMA_TFCPAD]
+ p-mode != XFRM_MODE_TUNNEL)
+ goto out;
break;
case IPPROTO_COMP:
@@ -172,7 +176,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_AUTH] ||
attrs[XFRMA_ALG_AUTH_TRUNC] ||
- attrs[XFRMA_ALG_CRYPT])
+ attrs[XFRMA_ALG_CRYPT] ||
+ attrs[XFRMA_TFCPAD])
goto out;
break;
@@ -186,6 +191,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ENCAP] ||
attrs[XFRMA_SEC_CTX]||
+ attrs[XFRMA_TFCPAD] ||
!attrs[XFRMA_COADDR])
goto out;
break;
@@ -439,6 +445,9 @@ static struct xfrm_state *xfrm_state_construct(struct net
*net,
goto error;
}
+ if (attrs[XFRMA_TFCPAD])
+ x-tfcpad = nla_get_u32(attrs[XFRMA_TFCPAD]);
+
if (attrs[XFRMA_COADDR]) {
x-coaddr = kmemdup(nla_data(attrs[XFRMA_COADDR]),
sizeof(*x-coaddr), GFP_KERNEL);
@@ -688,6 +697,9 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
if (x-encap)
NLA_PUT(skb, XFRMA_ENCAP, sizeof(*x-encap), x-encap);
+ if (x-tfcpad)
+ NLA_PUT_U32(skb, XFRMA_TFCPAD, x-tfcpad);
+
if (xfrm_mark_put(skb, x-mark))
goto nla_put_failure;
@@ -2122,6 +2134,7 @@ static const struct nla_policy xfrma_policy[XFRMA_MAX+1]
= {
[XFRMA_MIGRATE] = { .len = sizeof(struct xfrm_user_migrate) },
[XFRMA_KMADDRESS] = { .len = sizeof(struct xfrm_user_kmaddress) },
[XFRMA_MARK]= { .len = sizeof(struct xfrm_mark) },
+ [XFRMA_TFCPAD] = { .type = NLA_U32 },
};
static struct xfrm_link {
@@ -2301,6 +2314,8 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
l += nla_total_size(sizeof(*x-calg));
if (x-encap)
l += nla_total_size(sizeof(*x-encap));
+ if (x-tfcpad)
+ l += nla_total_size(sizeof(x-tfcpad));
if (x-security)
l += nla_total_size(sizeof(struct xfrm_user_sec_ctx) +
x-security-ctx_len);
--
1.7.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
Crypto Hardware Drivers?
Is this the right place to ask questions about writing a Linux device driver to make some crypto hardware on an ARM SoC work under the Linux crypto API? I have some hardware documentation that I don't yet know whether I can talk about (I know, if I can't then the driver will have difficulty being be GPL, and if it isn't an open license, it won't work...). I have some sample code for the hardware that is an incomplete and obsolete Linux module. I can see source code examples for things like the Padlock, IXP4xx hardware, etc. I have never touched any Linux kernel crypto code before this project. (I have done some stuff in userland, so the fact of crypto doesn't scare me.) At the moment I am trying to understand things like the parameter to crypto_register_alg(), how that is different from crypto_register_ahash()... And for a DMA case how data moves and who owns the memory. Stuff like that... Yes, the sources and Google are my friends, and Documentation/crypto/api-intro.txt has a very promising title but doesn't say terribly much inside. Are there any obvious key resources I should know about? (Any general pointers would be appreciated, too.) Thanks, -kb -- 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
