ok,I would test it
waiting for your good news
thanks
Hi all,
Do you know if there is any debug interface such as UART for NSS chip(not UART of CPU). I mean how QCA guys debug the NSS firmware issue. Do they use a special NSS chip or IPQXXXX SoC with UART interface?
I have worked out all the problems when registering the Crypto API with the extended crypto tests. The only problem I still have is CBC encrypt. I can't seem find anywhere in the source code if it is possible to save the IV for resume operations like on other crypto engines. This limits CBC encryption performance and reduces the maximum crypto-length to 64Kb - 1, so effectively 65520 due to block size. This is a problem for the cryptsetup benchmark because it passed a full 64Kb buffer.
Would there be a need to include an AEAD with HMAC(SHA224) ? And same question for DES vs 3DES-EDE... ECB(DES), CBC(DES) and authentic(hmac(x),cbc(des) can be included if people think it's useful.
From a driver point of view I think we should expose as much functionality as possible and let end users decide to use it or not. I also suggest to leave out the crypto-tool (benchmark).
As far as performance: Basically simple ciphers from user space is not really usable unless the block size like 8Kb or greater.
I have to fix another problem so we can use the crypto engine with aes-ctr as basis for gcm(aes). Other crypto drivers had problems with this as well and some have fixed it, others still not..
1 Like
The QSDK CFI drivers does not save the IV for subsequent encrypt/decrypt call for the same crypto session. You can refer to the patch I did to support standard CBC/CTR mode ops to the CFI driver. It’s for QSDK 11 but it’s applicable for QSDK 6 and later source. You may want to use what you think is applicable.
NSS only support SHA1 and SHA-256, so any AEAD mode will be limited to both hash mode. I did some work for an OpenVPN specific AES-CBC-SHA1/SHA256-HMAC driver but did not push it as it’s not useful for anything other that OpenVPN. I can upload the driver somewhere if you’re interested.
I know it doesn't, but it does program the IV registers for every new buffer. I was hoping that if we could skip writing the IV registers with new data it would use the previous result (IF it actually stores that back into the same registers).
SHA224 is SHA256 with a truncated result and a different IV so I can make that work.
I think for OpenWrt there will be more interest in OpenVPN vs IPSec. I had a look at the IPsec manager code already and I am hopeful that it could be made to work with the hardware offload features via the XFRM device.
So Yes! I'm interested to review your code. 
Based on the source (and I am using your git repo as basis), it should be possible to even do aes-xts natively (If I can figure out where to store the "tweak") and probably CCM(aes). I never looked closely at CCM code before so it will be interesting 
1 Like
The last commit on this branch should do it: https://github.com/facboy/openwrt/tree/kernel5.4-nss-qsdk10.0
2 Likes
Awesome! I’ll try it out.
Edit: grabbed the 2.4ghz VHT fix. That other commit is a major merge of tons of files - didn’t see any obvious changes - any changes in there worth adding?
no, you should just take the last commit, seeing as you already reverted @Ansuel's original 2.4Ghz VHT patch.
1 Like
Is it possible to keep IPSec in addition to OpenVPN? Or have a switch to chose which one to use, if having both is not possible?
I actually need IPSec, and at the moment I'm running a separate device to avoid overloading the OpenWRT one.
Of course you can have both at the same time on the same device if you want. However, at the moment of writing, it makes more sense to do software crypto for OpenVPN until there is a better way use kernel side offloading. IPSec is normally done in the Kernel (unless you use lib-ipsec with Strongswan which does crypto in user space).
@quarky, I was hoping the new OpenVPN DCO module would be able to help OpenVPN performance via AEAD, but I saw that even the keying modules are removed last month or so. So only GCM and Chacha. Do you have any news on this?
@drbrians, I discussed with ovpn-dco developers for a long time. Only GCM and Chacha. AES-CCM is also available for testing, but there is no plan to merge into the master branch.
subjec name: [ovpn-dco] AES-CCM available for testing
subjec name: [ovpn-dco] Is cbc-hmac supported?
"cut off old hardware"... Seems OpenVPN is leaving a lot of people behind with their DCO project.
Our "old" hardware seems to be able to do CCM, but I have no idea how many (paid) OpenVPN services will implement CCM. Paid Services are all going to support WireGuard and will continue to have IPSec support so even if hardware would support chacha people would switch to WireGuard probably.
Next step in my crypto exploration will be getting full ESP offload via NSS which was working on kernel 2.4/6 back in the day when OpenSwan had a KLIPS interface.
I’m not active in the OpenVPN development, sorry. I would think adding AES-CBC-SHA-HMAC support for the data channel would not be too difficult tho. From what I know, TLS is used for authentication and the data channel can use AES-CBC-SHA-HMAC. The IV seems to be generated per packet as well for OpenVPN.
DCO will definitely improve thruput. My simple hack improves performance 4 times, from 50mbps to 200mbps, so I believe the experts will definitely come up with better implementation.
I was hoping AEAD AES-CBC-SHA-HMAC would not be to difficult to include, but: ovpn-dco: remove cbc-hmac crypto. Performance improvement should be on par with IPSec when using "only" AEAD. IPSec could be improved when it could run directly through the NSS and be seen by the kernel as Hardware Offload in the NIC.
This was a hack for the qca-nss-cfi or a hack for the DCO? If for the DCO I would be very interested to see that. Not only will it benefit the IPQ806x NSS targets, it could improve other targets with hardware crypto as well.
It’s a hack that’s similar to DCO or QCA’s NSS DCA implementation for their IPQ807x targets. My codes are very ugly with patches to OpenVPN, NSS CFI driver and custom sendmsg kernel driver. It’s meant as a POC for me, so I didn’t release it. Let me clean up the codes somewhat and I’ll upload it somewhere.
My objective was also to adapt it subsequently for other SoCs, e.g. MT7621, but my day job kind of got in the way. Also, I realized I need to understand OpenVPN a lot more to proceed, so I decided to wait for OpenVPN’s solution.
Btw, ipq806x already support IPSec in the NSS firmware. It’s supposedly accelerated by the NSS firmware but I’ve never dabble in IPSec so I didn’t try it. The NSS client drivers already have IPSec support. You may want to try adding those in and try.
From what I understand, the NSS driver will intercept IPSec traffic, much like PPPoE, and pass it on to the Linux stack and conversely sends Linux network traffic over the IPSec tunnel. Krait CPU load should be low.
From how I read the code it is creating a virtual interface based on the IPSECx interface created via the openSwan KLIPS stack. This is not compatible with the current netlink stack. The XFRM device is similar in usage but is created in a different way so I have to study the code a bit more.
I would be interested to see those patches cause it would give me a starting point on how to "hack" openVPN to the MT7621. Speaking of MT7621, I am very far in the meantime with the EIP93 implementation but I'm still not able to match the performance of my Mikrotik RB760 running their RouterOS. Its one of the reasons why I'm looking into this crypto code: it might give me some additional ideas on how to improve performance.
I've uploaded my code hacks here:
https://app.box.com/s/vmtjhpdexn2mb18scfjeqbem9mzzi6io
It's uploaded mainly as a patch set. Feel free to use it any way you can. I doubt you will find it useful tho ... haha 
I've included a short 'read me' in the tar file. Hopefully it will make it less confusing for you.
I have a Linksys EA7500AH-v2 which is using the MT7621A SoCs, so I'm very interested in your progress with your work on the EIP93 driver.
2 Likes
@quarky Thanks!! It looks very interesting how you made a special openvpn aead.
I will clean up my patches for the nss-cfi and nss-crypto. Both are needed since the original driver doesn't allow to set the keys again within the same context, while the Crypto API does allow that.
Multi-buffer is on the same principle as I am doing for the EIP-93. That one is also not able to do scatter-gather DMA. For the NSS it should possible to upgrade the firmware and implement scatter-gather DMA.
To pass the crypto-extended tests it is also necessary to allow a separate Source and Destination which is also included in my patches.
I also modified the free session-id part since I was running out of sessions when running cryptsetup benchmarks. For some reason (which I haven't figured out yet), the original version frees the session in a separate delayed work-queue.
1 Like
@quarky @Ansuel - FYSA- some of the recent master additions seemed to have moved several critical files around enough that rebase is going to take a little work (not that hard)- target/linux/ipq806x/files-5.4 has now fully become target/linux/ipq806x/files
Now that 5.4 + NSS is stable - what would you recommend for an initial set of patches to start getting NSS NAT in to master (rebuild some of the initial patches, new patches?). I'm perfectly happy with testing and helping organize the commits to clean up our branch to get it ready for integration.
Getting this during rebase (older commits in the branch need some clean up and simple consolidation):
CONFLICT (file location): target/linux/ipq806x/files-5.4/net/netfilter/nf_conntrack_dscpremark_ext.c added in 07cb17f7fd (Update target patches and config) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to target/linux/ipq806x/files/net/netfilter/nf_conntrack_dscpremark_ext.c.
CONFLICT (file location): target/linux/ipq806x/files-5.4/include/net/netfilter/nf_conntrack_dscpremark_ext.h added in 07cb17f7fd (Update target patches and config) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to target/linux/ipq806x/files/include/net/netfilter/nf_conntrack_dscpremark_ext.h.
CONFLICT (file location): target/linux/ipq806x/files-5.4/include/linux/regulator/nss-volt-ipq806x.h added in 07cb17f7fd (Update target patches and config) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to target/linux/ipq806x/files/include/linux/regulator/nss-volt-ipq806x.h.
CONFLICT (file location): target/linux/ipq806x/files-5.4/drivers/regulator/nss-volt-ipq806x.c added in 07cb17f7fd (Update target patches and config) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to target/linux/ipq806x/files/drivers/regulator/nss-volt-ipq806x.c.
error: could not apply 07cb17f7fd... Update target patches and config
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 07cb17f7fd... Update target patches and config
[HTPC@localhost openwrt]$ git status
interactive rebase in progress; onto 498fb1b8aa
Last commands done (3 commands done):
pick 156382770f Add needed patch for nss driver
pick 07cb17f7fd Update target patches and config
(see more in file .git/rebase-merge/done)
Next commands to do (63 remaining commands):
pick 0cc354d269 Use qsdk10.0 for crypto driver
pick a65e4e2e06 Add qca-nss-cfi support
(use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'kernel5.4-nss-qsdk10.0' on '498fb1b8aa'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-r7800.dts
Unmerged paths:
(use "git restore --staged <file>..." to unstage)
(use "git add <file>..." to mark resolution)
added by them: target/linux/ipq806x/files/drivers/regulator/nss-volt-ipq806x.c
added by them: target/linux/ipq806x/files/include/linux/regulator/nss-volt-ipq806x.h
added by them: target/linux/ipq806x/files/include/net/netfilter/nf_conntrack_dscpremark_ext.h
added by them: target/linux/ipq806x/files/net/netfilter/nf_conntrack_dscpremark_ext.c