Date: Mon, 24 Oct 2016 12:09:13 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Andriy Voskoboinyk <avos@freebsd.org> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: net80211 offload, crypto offload pieces Message-ID: <CAJ-Vmokw1ggg%2B1TqmmHdNwPPRU-JgfUvf27bEv8wfkjopzdRyw@mail.gmail.com> In-Reply-To: <op.ypuph6ly4dikkl@localhost> References: <CAJ-Vmo=EuDFnA8vkH7nt4ropyXSSgKJxr%2BV8Q7GvctpUq-Fz3g@mail.gmail.com> <op.ypuph6ly4dikkl@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 October 2016 at 11:55, Andriy Voskoboinyk <avos@freebsd.org> 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 > <adrian@freebsd.org>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokw1ggg%2B1TqmmHdNwPPRU-JgfUvf27bEv8wfkjopzdRyw>