ROG Rapture GT-AC5300 (Owners)

[sfx2000]

The OS is compiled in 64-bit, including the CFE.

EDIT: hm I wonder if they changed it, because the prebuilt binary blobs report as being 32-bit in recent GPLs - they used to be 64-bit.

EDIT2: Can't remember where I saw a reference to 64-bit beside the CFE boot banner. <shrug>

I still haven't taken a deep dive, but it makes sense to keep things 32-bit, due to the pre-built binaries from third parties - it's less overhead from the 32/64 context switch, and Aarch32 still benefits from the ARMv8 instruction set...

edit - pre-built binaries being ARMv7-a...

 

[sfx2000]

@RMerlin - 32/64 - OpenSSL 1.0.2j is still being built on ARMv7-a according to @maylyn's data. which is ok, but also notice glibc, which is nice compared to the old uclibc...

Interesting to note that they're sticking with OpenSSL 1.0.2 rather than leaping into 1.1 - we know the impact there - but curious that they didn't take to musl, rather going with glibc - third party libs perhaps?

The new BSP is interesting, but it's gonna be a bit of work for AsusWRT forks because of all the changes - new kernel, new GCC, new LibC, and mixed armv7-a/armv8 code...

Anyways - the chip has a good feature set, more than enough horsepower, and being on a smaller geometry node (28nm vs. 40 nm) and DVFS - excellent foundation to build from...

 

[sfx2000]

excellent foundation to build from...

and that being said - firmware hackers like @RMerlin, @hggomes, @john9527, @Voxel, @ryzhov_al, and @kvic - could be a great collaborative effort - heck, I would join in

This is likely a chip and a BPS/GPL that can be tuned pretty hard...

sfx

 

[kvic]

putting things into perspective... with OpenVPN 2.4 and the AES-128-GCM support - wasn't so great for ARMv7, but...

@kvic - check this out man...
@maylyn - thanks for running these

openssl speed -evp aes-128-gcm

GS-AC5300 - Broadcom "B53"

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 103664.09k 280881.86k 517767.54k 664993.74k 716743.04k​

Intel NUC - Braswell N3700 (airmont 2.4GHz)

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 125214.28k 235705.28k 322178.22k 358748.16k 369145.17k
​

Interesting...

Something isn't right with Broadcom's SDK. CBC can't beat GCM. Either software isn't optimised properly or the hardware stays behind its time on crypto functionality. But very surprised to see Braswell @ 2.4GHz was beaten to death by ARMv8 @ 1.8GHz.

 

[sfx2000]

Something isn't right with Broadcom's SDK. CBC can't beat GCM. Either software isn't optimised properly or the hardware stays behind its time on crypto functionality. But very surprised to see Braswell @ 2.4GHz was beaten to death by ARMv8 @ 1.8GHz.

on ARMv7-a - CBC has been faster than GCM - well known - Intel has done a lot of great work on GCM wtih AES-NI/SSE code paths there...

Just interesting to note that the Asus/Broadcom SDK is still running code in ARMv7-a mode, not ARMv8, and this chip does pretty well...

 

[ryzhov_al]

Offtopic

I was on Broadcom-based devices since WL500gpv1 and I'm glad it's over.

… could be a great collaborative effort - heck, I would join in

This is likely a chip and a BPS/GPL that can be tuned pretty hard...

As for me, I'm MIPS-addicted for next couple of years. Mediatek MT7621 (2 cores, 2 theads on every core) gives me enough for my needs. Up to 350mbps IPSec in real life via h/w acceleration, h/w QoS, h/w accelerated IPoE/PPPoE/PPTP and other cool features on fully open source f/w.

 

[hggomes]

The OS is compiled in 64-bit, including the CFE.

EDIT: hm I wonder if they changed it, because the prebuilt binary blobs report as being 32-bit in recent GPLs - they used to be 64-bit.

EDIT2: Can't remember where I saw a reference to 64-bit beside the CFE boot banner. <shrug>

I never seen any 64bit binary blob file available on GT-AC5300, where you've seen it? First available GPL? If you check during compile time you will see it always using 32bit, not 64.

 

[hggomes]

Indeed, you are right about it:

https://pastebin.com/xSrcxPgK


Seems to me a mix of 32 and 64bit, I can compile it again and check the root filesystem recursively in order to check which parts are 32 and 64bit.

But here's the thing, it's not possible to run 64bit binary blobs on a 32bit OS.

 

[RMerlin]

Indeed, you are right about it:

https://pastebin.com/xSrcxPgK


Seems to me a mix of 32 and 64bit, I can compile it again and check the root filesystem recursively in order to check which parts are 32 and 64bit.

But here's the thing, it's not possible to run 64bit binary blobs on a 32bit OS.

Can you check the kernel? I suspect they might have a 64-bit kernel (to go with Broadcom's prebuilt binaries which show at 64-bit), but have the rest of the userspace content in 32-bit. That would probably be a good compromise.

 

[RMerlin]

Interesting to note that they're sticking with OpenSSL 1.0.2 rather than leaping into 1.1 - we know the impact there - but curious that they didn't take to musl, rather going with glibc - third party libs perhaps?

1.1.0 introduces API changes, so it's not a drop-in replacement like 1.0.2 was for 1.0.0. Since Asus only went from 1.0.0 to 1.0.2 because I did the necessary legwork (and I also pointed out 1.0.0 was going EOL last year), I suspect they aren't gonna move to 1.1.0 on their own, and I can't do that move either due to the closed-source components linked against 1.0.x. Plus, believe it or not, but they use THREE different OpenSSL versions in their firmware, probably either for fear of breaking things, or due to arcane issues they encountered when moving everything to 1.0.2. The Broadcom modem driver for instance is linked against 1.0.0, and their Download Master stuff is linked against a third one (don't remember which version).

 

[RMerlin]

Something isn't right with Broadcom's SDK. CBC can't beat GCM.

From what I recall, one of the benefits of GCM is that you don't need to compute a separate HMAC. That means that the performance gain is more visible at the application level than if you just a straight compare of the cipher itself.

 

[hggomes]

Can you check the kernel? I suspect they might have a 64-bit kernel (to go with Broadcom's prebuilt binaries which show at 64-bit), but have the rest of the userspace content in 32-bit. That would probably be a good compromise.

Sure, I'll check it later today and let you know.

 

[hggomes]

Compiling...

https://pastebin.com/bZDD3pJj

 

[RMerlin]

Compiling...

https://pastebin.com/bZDD3pJj

64-bit kernel, and a mixture of 32/64 for userspace. That makes sense, from a compatibility point of view - custom code won't need to be updated to work under 64-bit.

 

[hggomes]

Exactly.

 

[RMerlin]

curious that they didn't take to musl, rather going with glibc - third party libs perhaps?

They're probably bound to what Broadcom supports in the SDK.

 

[hggomes]

Here's the entire GT-AC5300 FW structure for further analysis:

http://www.mediafire.com/file/ar5303ue4t7kkrb/gt-ac5300_fs.tar.bz2 (725MB)

The OS / Kernel is 64bit like previously discussed, but ARM architecture / instructions curiously still ARMv7-a, this should be changed to ARMv8.

 

[sfx2000]

From what I recall, one of the benefits of GCM is that you don't need to compute a separate HMAC. That means that the performance gain is more visible at the application level than if you just a straight compare of the cipher itself.

Intel does some clever SSE/AVX memory tricks to improve OpenSSL performance, it's not just AES-NI and RDRAND there... and there, the Haswell and later cores absolutely scream at GCM performance... Silvermont/Airmont have SSE, AES-NI, and RDRAND, but they don't have AVX/AVX2...

With this chip, I'm totally ok with the GCM performance... as this is consistent with ARM, and better than older chips pre-ARMv8

 

[sfx2000]

They're probably bound to what Broadcom supports in the SDK.

Yep - that everything works with glibc is a good step moving forward - like OpenSSL, moving to a new libc implementation is non-trivial...

 

[sfx2000]

Since Asus only went from 1.0.0 to 1.0.2 because I did the necessary legwork (and I also pointed out 1.0.0 was going EOL last year), I suspect they aren't gonna move to 1.1.0 on their own, and I can't do that move either due to the closed-source components linked against 1.0.x. Plus, believe it or not, but they use THREE different OpenSSL versions in their firmware, probably either for fear of breaking things, or due to arcane issues they encountered when moving everything to 1.0.2. The Broadcom modem driver for instance is linked against 1.0.0, and their Download Master stuff is linked against a third one (don't remember which version).

I know that 1.1 isn't really a drop-in for 1.0.* - I forgot that there was multiples there - and it's something that perhaps with the new SDK, Asus can get caught up and unify them - makes security patching much easier rather than trying to backport (and test) patches across multiple versions..