netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Dillow <dave@thedillows.org>
To: netdev@oss.sgi.com
Cc: dave@thedillows.org
Subject: [RFC BK 14/22] xfrm offload v2: typhoon: add inbound offload result processing
Date: Mon, 10 Jan 2005 10:37:01 -0500	[thread overview]
Message-ID: <20040110014300.23@ori.thedillows.org> (raw)
In-Reply-To: 20040110014300.22@ori.thedillows.org

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/10 00:54:54-05:00 dave@thedillows.org 
#   Add inbound packet crypto result processing to the Typhoon driver.
#   
#   Signed-off-by: David Dillow <dave@thedillows.org>
# 
# drivers/net/typhoon.c
#   2005/01/10 00:54:37-05:00 dave@thedillows.org +42 -0
#   Add inbound packet crypto result processing to the Typhoon driver.
#   
#   Signed-off-by: David Dillow <dave@thedillows.org>
# 
diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c
--- a/drivers/net/typhoon.c	2005-01-10 01:17:58 -05:00
+++ b/drivers/net/typhoon.c	2005-01-10 01:17:58 -05:00
@@ -130,6 +130,7 @@
 #include <asm/checksum.h>
 #include <linux/version.h>
 #include <linux/dma-mapping.h>
+#include <net/xfrm.h>
 
 #include "typhoon.h"
 #include "typhoon-firmware.h"
@@ -1680,6 +1681,43 @@
 	return 0;
 }
 
+static inline void
+typhoon_ipsec_rx(struct sk_buff *skb, u16 results)
+{
+#define CHECK_OFFLOAD(good, bad) \
+	do { if(results & (good|bad)) { \
+		unsigned int tmp = XFRM_OFFLOAD_CONF | XFRM_OFFLOAD_AUTH; \
+		tmp |= (results & good) ?  XFRM_OFFLOAD_AUTH_OK : \
+					   XFRM_OFFLOAD_AUTH_FAIL; \
+		if(skb_put_xfrm_result(skb, tmp, i)) \
+				return; \
+		i++; \
+	} } while(0)
+
+	/* We have no way to determine what the order of the SAs were on
+	 * the wire, just the 1st AH seen, the 1st ESP seen, etc.
+	 *
+	 * We just walk the stack, and pretend that AH SAs get decypted
+	 * so that if we get the order wrong, the worst case scenerio is
+	 * that we indicate the failure on the wrong SA, since we'll need
+	 * to match all SAs against the policy.
+	 *
+	 * We get a "ESP good" indication for null auth hash on ESP.
+	 */
+	/* XXX think more about security indications -- can I craft a
+	 * packet to do bad things -- maybe a NULL auth ESP packet,
+	 * and a failed AH packet?
+	 */
+	int i = 0;
+
+	CHECK_OFFLOAD(TYPHOON_RX_AH1_GOOD, TYPHOON_RX_AH1_FAIL);
+	CHECK_OFFLOAD(TYPHOON_RX_ESP1_GOOD, TYPHOON_RX_ESP1_FAIL);
+	CHECK_OFFLOAD(TYPHOON_RX_AH2_GOOD, TYPHOON_RX_AH2_FAIL);
+	CHECK_OFFLOAD(TYPHOON_RX_ESP2_GOOD, TYPHOON_RX_ESP2_FAIL);
+
+#undef CHECK_OFFLOAD
+}
+
 static int
 typhoon_rx(struct typhoon *tp, struct basic_ring *rxRing, volatile u32 * ready,
 	   volatile u32 * cleared, int budget)
@@ -1744,6 +1782,10 @@
 			new_skb->ip_summed = CHECKSUM_UNNECESSARY;
 		} else
 			new_skb->ip_summed = CHECKSUM_NONE;
+
+		if((rx->rxStatus & TYPHOON_RX_IPSEC) &&
+				!(rx->rxStatus & TYPHOON_RX_IP_FRAG))
+			typhoon_ipsec_rx(new_skb, rx->ipsecResults);
 
 		spin_lock(&tp->state_lock);
 		if(tp->vlgrp != NULL && rx->rxStatus & TYPHOON_RX_VLAN)

  reply	other threads:[~2005-01-10 15:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 15:36 [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto David Dillow
2005-01-10 15:36 ` [RFC BK 1/22] xfrm offload v2: Add direction information to xfrm_state David Dillow
2005-01-10 15:36   ` [RFC BK 2/22] xfrm offload v2: Add xfrm offload management calls to struct netdevice David Dillow
2005-01-10 15:36     ` [RFC BK 3/22] xfrm offload v2: Add offload management routines David Dillow
2005-01-10 15:36       ` [RFC BK 4/22] xfrm offload v2: Try to offload inbound xfrm_states David Dillow
2005-01-10 15:37         ` [RFC BK 5/22] xfrm offload v2: Attempt to offload bundled xfrm_states for outbound xfrms David Dillow
2005-01-10 15:37           ` [RFC BK 6/22] xfrm offload v2: add a parameter to xfrm_prune_bundles() David Dillow
2005-01-10 15:37             ` [RFC BK 7/22] xfrm offload v2: Allow device drivers to force recalculation of offloads David Dillow
2005-01-10 15:37               ` [RFC BK 8/22] xfrm offload v2: Add routines to manage applied offloads per skb David Dillow
2005-01-10 15:37                 ` [RFC BK 9/22] xfrm offload v2: Split AH header initialization from zeroing of mutable fields David Dillow
2005-01-10 15:37                   ` [RFC BK 10/22] xfrm offload v2: Add offloading of outbound AH & ESP packets David Dillow
2005-01-10 15:37                     ` [RFC BK 11/22] xfrm offload v2: Add offloading of inbound " David Dillow
2005-01-10 15:37                       ` [RFC BK 12/22] xfrm offload v2: Add ethtool support for crypto offload control David Dillow
2005-01-10 15:37                         ` [RFC BK 13/22] xfrm offload v2: typhoon: Make the ipsec descriptor match actual usage David Dillow
2005-01-10 15:37                           ` David Dillow [this message]
2005-01-10 15:37                             ` [RFC BK 15/22] xfrm offload v2: typhoon: add outbound offload processing David Dillow
2005-01-10 15:37                               ` [RFC BK 16/22] xfrm offload v2: typhoon: collect crypto offload capabilities David Dillow
2005-01-10 15:37                                 ` [RFC BK 17/22] xfrm offload v2: typhoon: split out setting of offloaded tasks David Dillow
2005-01-10 15:37                                   ` [RFC BK 18/22] xfrm offload v2: typhoon: add validation of offloaded xfrm_states David Dillow
2005-01-10 15:37                                     ` [RFC BK 19/22] xfrm offload v2: typhoon: add loading of xfrm_states to hardware David Dillow
2005-01-10 15:37                                       ` [RFC BK 20/22] xfrm offload v2: typhoon: add management of outbound bundles David Dillow
2005-01-10 15:37                                         ` [RFC BK 21/22] xfrm offload v2: typhoon: add callbacks to support crypto offload David Dillow
2005-01-10 15:37                                           ` [RFC BK 22/22] xfrm offload v2: Add some documentation for the IPSEC " David Dillow
2005-01-17 19:00 ` [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto James Morris
2005-01-20 17:22   ` Dave Dillow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040110014300.23@ori.thedillows.org \
    --to=dave@thedillows.org \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).