I made a NSS build for C2600 and EA8500 in community builds. I have one person reporting they tried to load the EA8500 build but it didn’t boot. Anyone else build or try a NSS build on a C2600 or EA8500 and were successful? (if so did you have to modify anything to get it to work, I don’t have either of these devices but I’m trying to make a easy to download build so that people try it out).
same problem withlinksys ea7500 v1, I would try too,but nobody can make it for the moment
can you provide a link to the build or git repo?
Just to let you know I'm working on the NSS Crypto driver at the moment. I fixed most of the problems using the extended crypto tests that are disabled by default in the kernel.
I added AES-ECB because it doesn't need an IV, which is a problem to do non-copy scatter lists. For ECB I am able to use "multi-buffer" scatter lists. The "nss-ecb-aes" can be used in combination with e.g. AES-XTS as used in DM-Crypt.
root@OpenWrt:/# cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 41269 iterations per second for 256-bit key PBKDF2-sha256 75328 iterations per second for 256-bit key PBKDF2-sha512 N/A PBKDF2-ripemd160 N/A PBKDF2-whirlpool N/A argon2i 4 iterations, 71144 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) argon2id 4 iterations, 70000 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc 128b 44.4 MiB/s 42.9 MiB/s serpent-cbc 128b N/A N/A twofish-cbc 128b N/A N/A aes-cbc 256b 37.0 MiB/s 33.8 MiB/s serpent-cbc 256b N/A N/A twofish-cbc 256b N/A N/A aes-xts 256b 41.4 MiB/s 42.9 MiB/s serpent-xts 256b N/A N/A twofish-xts 256b N/A N/A aes-xts 512b 37.6 MiB/s 34.8 MiB/s serpent-xts 512b N/A N/A twofish-xts 512b N/A N/A # Algorithm | Key | Encryption | Decryption aes-cbc 128b 48.0 MiB/s 43.6 MiB/s serpent-cbc 128b N/A N/A twofish-cbc 128b N/A N/A aes-cbc 256b 37.1 MiB/s 34.5 MiB/s serpent-cbc 256b N/A N/A twofish-cbc 256b N/A N/A aes-xts 256b 89.4 MiB/s 90.1 MiB/s serpent-xts 256b N/A N/A twofish-xts 256b N/A N/A aes-xts 512b 82.8 MiB/s 78.5 MiB/s serpent-xts 512b N/A N/A twofish-xts 512b N/A N/A root@OpenWrt:/# grep "xts" /proc/crypto name : xts(aes) driver : xts(ecb(aes-generic)) module : xts name : xts(aes) driver : xts(nss-ecb-aes) module : xts
Updates will follow...
@kipper - made a build for the C2600 (It is untested). Feel free to test it and give feedback.
@ACwifidude: is your build based on the dts that @Ansuel has made available in his repo? If it is, it probably won't work as I had tested it myself. It seems that some tweaks will be required in order to make it work (there's a GPL available for the C2600 but I lack the knowledge to contribute to the fix).
I am using closed source QSDK v11.2 and currently struggling with getting ingress shaping to work on eth0 with NSS enabled(IPQ6018 reference board) since ifb is not supported.
Egress shaping works okay right now . Am using the following
tc qdisc add dev eth0 root handle 1: nsshtb r2q 20
tc class add dev eth0 parent 1: classid 1:1 nsshtb rate 1000Mbit crate 1000Mbit burst 100k cburst 100k
tc class add dev eth0 parent 1:1 classid 1:2 nsshtb rate 2Mbit crate 2Mbit burst 30k cburst 30k priority 0
tc class add dev eth0 parent 1:1 classid 1:3 nsshtb rate 40Mbit crate 100Mbit burst 30k cburst 30k priority 1
tc class add dev eth0 parent 1:1 classid 1:4 nsshtb rate 0Mbit crate 1000Mbit burst 30k cburst 30k priority 2
tc qdisc add dev eth0 parent 1:2 handle 2: nsspfifo limit 100
tc qdisc add dev eth0 parent 1:3 handle 3: nsspfifo limit 100
tc qdisc add dev eth0 parent 1:4 handle 4: nsspfifo limit 100 set_default
Any idea how to get it working ? Also, are you aware about IGS interface https://source.codeaurora.org/quic/cc-qrdk/oss/lklm/nss-drv/log/?h=NHSS.QSDK.11.3&qt=grep&q=IGS
not sure how to use this one though..
Kong made a tweak that got the EA8500 up and running. It will likely help your device too. If you want to test it I can help troubleshoot / tweak the C2600 .dts
The IGS interface is only available for the ipq60xx and ipq807x SoCs. So I could not try it as I only have an ipq8065 router.
From the QSDK 11.3 source tho, it looks like the IGS interface is used together with the Linux IFB interface for ingress shaping. Since you’re already using egress shaping that means that you have the nss-clients qdisc module loaded. If I’m not wrong you just need to create a new IFB interface and configure qdisc with the ‘tc’ utility. That should get ingress shaping up.
Yes I guess it has to be used with IFB interface. Following is what I tried ,
ip link add name ieth0 type ifb ip link set dev ieth0 up tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev ieth0
And then when I try to attach qdisc using
tc qdisc add dev ieth0 root handle 1: nsshtb r2q 20
It gives me the following error,
[ 625.309606] nss_htb_init_qdisc:failed to initialize htb qdisc 10000 in nss [ 678.679022] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11) is root [ 678.679060] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11) init dev: ffffffc02fcb4000 [ 678.684959] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11) init qdisc: ffffffc02ee26000, not bridge [ 678.693741] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11) init root: ffffffc02ee26000, qos tag: 10000, parent: ffffffff rootid: nsshtb owner: ffffffbffce6f400 [ 678.703054] nss_qdisc_init:init qdisc type 11 : ffffffc02ee26000, ROOT [ 678.717853] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11): is interface [ 678.724979] nss_qdisc_init:Qdisc ffffffc02ee26000 (type 11): interface unknown to nss driver ieth0
I guess direct ifb might not work, there has to be some nss version of it.. But not sure how to create such an interface.
Finally... Figured it out..
It seems there is a new action introduced called nssmirred and its syntax is also a bit different,
This is how to create an ifb interface that is compatible with NSS,
ip link add name ieth0 type ifb
ip link set dev ieth0 up
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action nssmirred redirect dev ieth0 fromdev eth0
Will check if it works now..
Made a ea7500-v1 build. It is untested - so be tftp ready.
If it doesn’t load I can work to troubleshoot the .dts file.
ok,I would test it
waiting for your good news
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..
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
The last commit on this branch should do it: https://github.com/facboy/openwrt/tree/kernel5.4-nss-qsdk10.0
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?