Re-implement the SPL sysmodule.

[SciresM]

Switchbrew docs

Wanted extensions: (TODO: fill this up)

[m4xw]

Since this is the crypto engine/core, from my understanding, isn't it desireable to "not do your own crypto" and try to get a ssl library implemented to provide functionality and use best practice implementation, or keep it short with a ARM assembler implementation of the AES algo?

Or rather just C/C++? In our enterprise enviroment we generally try to just stick to assembler or known implementations for crypto or often used logarithmics and don't reinvent the wheel twice.

At which point in time will this be loaded? I am still looking through all the docs but it will take some time beside my daywork and eating up the docs to write some code.

Did you guys set on a coding style yet? I would recommend the NASA guidelines if possible. Especially in the first stage.

Edit: Does the Tegra actually have a crypto chip?
I am just skipping a bit through the code, and it seems like it. I still want to put that in the room, sooner or later we gonna need more advanced crypto and should maybe focus to get hardware acceleration running for a known lib?
Just what is everyones opinion on this matter

[hexkyz]

The Tegra has its own hardware crypto engine (Security Engine or SE for short). I believe it's desirable to ensure compatibility with it and the idea here is to extend on the SPL module (which is loaded by the kernel as part of its built-in system modules' package) in order to provide a backend for higher level applications (such as a SSL library, for example).
This is how the Horizon OS tackles this issue (Security Engine -> TrustZone -> SPL -> User) and the goal would be to re-implement this module in a way that allows customization of what gets exposed to the user.