From owner-freebsd-wireless@freebsd.org Mon Oct 24 19:09:15 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C315C1F1E3 for ; Mon, 24 Oct 2016 19:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B318C18; Mon, 24 Oct 2016 19:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-yb0-x231.google.com with SMTP id 205so6092516ybz.5; Mon, 24 Oct 2016 12:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=KglK8xWYwAcJiZB6i+c6mBMdalKwklCCDdV6T6Iihac=; b=LVb3GgzvLUZHWb582PoO9/UwU/1HazbHegrk76OKf47AQ/l3hPziK3cNFjXfb5OqQw by8ZAnlRfyQiUMd56BkkFE/K8GUAaei6TlZ4VbyAdqPh44ZNmAHrG7IIZycm8dXVL560 TeqKBos3MTDXskOy21KlAbVZ/RbIFcIav6c3QTcf3Lhig8pyzGEOoTPGAMtCEWm5tT/e riw7pL8iEPGZb+p12mZY5YfhyQ/RJN4jkasFGx5gcLRfyuNpJ43dohM/Fx+EOGcFTtD/ 3vNJXvH8HhqDXDTix/uxs3Jhdo5A0UjpVR2lGKV/eUvuuICxPcEo2I4kn32YBCIGQTN0 5AfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=KglK8xWYwAcJiZB6i+c6mBMdalKwklCCDdV6T6Iihac=; b=KPoChlwAM14/cU/hvWPxyw1Dc9wzT/nuzNObbavFZ6jADpXkzZkhivBGnKQcalpkgM ND8GpeFVKmcWWmZr0Zo3z8W4xZ1QcIrrXIDDyVRZkW9bg9Br2+E0YpiP82D8QSW4ipBw P0dEKcoO8th18xsnA53g5hmwyXBnAP1O/0G4tNgpVi2MsW1cANf7RTMjcQB8DQAQP1WQ Gd+LlV42AG98ch3Tm6j0L41y9QQUDNI4xp6ujo3cBlI7fgXhZheI6nti3y07yYWTohv3 FOW9I9QD9BtwV5t7cFA6SVfcy7YTS+1rRlLNbXGvn2ZAxvZEmojrmIiy4blSR3oWJdBD +txg== X-Gm-Message-State: ABUngveUw+L5CArJXzTAu4sajUt0C0F7IDeCDoeR5gp40F0lLnnmDciCcSjbfIz0618RE7dNagM6Lhh9T0m5sA== X-Received: by 10.36.73.19 with SMTP id z19mr3421806ita.29.1477336153807; Mon, 24 Oct 2016 12:09:13 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.141.129 with HTTP; Mon, 24 Oct 2016 12:09:13 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Mon, 24 Oct 2016 12:09:13 -0700 X-Google-Sender-Auth: wylqq_-6e4qLvfbwBdVJqRcqQwQ Message-ID: Subject: Re: net80211 offload, crypto offload pieces To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:09:15 -0000 On 24 October 2016 at 11:55, Andriy Voskoboinyk wrote: > Mon, 24 Oct 2016 19:36:08 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Adrian Chadd > : > > Hi! > >> hiya, >> >> So I have my ath10k driver port up and running in 11abg (not n/ac) >> mode. The hardware is .. highly offload-y. There are three/four data >> pipelines - "raw" mode, "native wifi" mode, "ethernet" mode, and >> "management TX/RX" mode. >> >> * "raw" mode is raw, untouched 802.11 frames. This is the most >> flexible but it means we have to do software encryption and A-MSDU >> encap/decap. >> * "native wifi" mode is microsoft 802.11 framing. This is like 802.11, >> but there's no QoS field. Yes, the QoS field is in the descriptor >> field and the hardware will add/delete it for you. >> * "ethernet" mode is 802.3 encap/decap ethernet. >> * "management" mode is a separate TX/RX pipeline for management frames >> (eg beacons, probe requests, etc.) The firmware is the normal target >> for management frames and it takes care of sending up frames that the >> stack needs to see. >> >> Now, this makes crypto a bit of a pain to implement. Notably: >> >> * There's no hardware key index that we see. It's all done per-peer. >> So, each peer has the 0..4 wep key slot, then I think 0..4 for >> pairwise keys (even though we only support keyidx 0 for now) with >> flags to say "current TX key (for WEP), "pairwise", "group" keys. >> * The group key is per-peer - so no, you don't program it in with an >> address of ff:ff:ff:ff:ff:ff. It needs to be the BSS MAC. > > > > That's similar to wpi(4) / iwn(4) crypto: > - they has some special 'set global WEP keys 0..3' firmware command; > - every node (24 for wpi(4), 16 (?) for iwn(4) has its own Rx key table > (8 pairwise + 8 group). > - encryption key is set in Tx descriptor. > (BTW, that's already implemented in wpi(4) (AES-CCM only)) Ok, so good - this work can be used by the other NICs in a mostly immediate fashion. >> * For raw mode, you don't need any keys, just send frames. >> * For native wifi (and I'm guessing ethernet) you have to add a CLEAR >> GTK/PMK key to a peer before it'll start transmitting traffic to said >> peer - the firmware buffers frames until the four-way handshake is >> done. >> * For QoS traffic the hardware/firmware seems to corrupt software >> encryption. Which, if you think about it, makes sense - the hardware >> has to insert the QoS header into the frame and then transmit it, >> which means if it makes /any/ change to make the packet contents not >> line up, it won't decrypt right. >> >> The mac80211/ath10k paths do software encryption/decryption for GCMP, >> which we currently don't support. So there /is/ some way to do >> completely software encryption/decryption, as long as it's non-QoS >> management frame style traffic. >> >> So those are the annoying bits. The net80211 bits that need to change ar= e: >> >> * The encryption hardware doesn't want an IV, FCS or MIC - it instead >> will add the IV, MIC and WEP FCS itself. So during encap we shouldn't >> provide it. >> * .. and for management traffic, it depends. Sometimes it does, >> sometimes it doesn't. >> * For decryption, the hardware will fully decrypt the frame, including >> stripping IV/MIC/WEPFCS. It instead passes up flags in the descriptor >> to say "decrypted ok", "MIC failed", "CRC/FCS failed", etc. So a lot >> of the decap path can't run - there's no IV to get a keyindex from, >> and there's no MIC to check against / strip. > > > > run(4) does something similar - it does not call ieee80211_crypto_encap() > for Tx and checks Rx descriptor flags before passing the frame to net8021= 1 Ok. So we should fix this in the TX encap path in net80211 first, then make sure we call crypto_encap in run. The reason? So when we grow say, GCMP (for management frame protection) we can do hybrid software/hardware crypto schemes. -adrian