![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / arch / arm / sunxi
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Rework sun8i crypto. - Preallocate tasks and DMA maps together for now, for 4k transfers. - Confine setup of the task descriptor to a single function, without bus_dmamap_t as an input; just use the preallocated DMA maps. - Take the DMA map part out of sun8i_crypto_buf. => Not much left here, just a dmamem segment and kva mapping. This should make it easier to use with opencrypto.
Pull up following revision(s) (requested by riastradh in ticket #912): sys/arch/arm/dts/sun50i-a64.dtsi: revision 1.14 sys/arch/evbarm/conf/GENERIC64: revision 1.116 sys/arch/evbarm/conf/GENERIC64: revision 1.131 sys/arch/arm/sunxi/sun50i_a64_ccu.c: revision 1.21 sys/arch/arm/sunxi/sun50i_a64_ccu.c: revision 1.22 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.10 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.11 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.12 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.1 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.2 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.3 sys/arch/arm/sunxi/sun8i_crypto.h: revision 1.1 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.4 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.5 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.6 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.7 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.8 sys/arch/arm/sunxi/sun8i_crypto.c: revision 1.9 sys/arch/arm/sunxi/files.sunxi: revision 1.67 Add crypto engine clock Add SUNXI_CCU_NM_ROUND_DOWN to CE clock, fix pll parents to use 2X outputs Add crypto engine block. Draft driver for Allwinner Crypto Engine. Found on, e.g., the Pinebook. Only used for TRNG at the moment, but hooking it up to opencrypto(9) shouldn't be too hard if anyone still cares about that these days. The distribution of the alleged TRNG is very nonuniform distributed seems to alternate between toward runs with exceptionally high fractions of 0 bits and runs with exceptionally high fractions of 1 bits -- initially all my samples were mostly 0's, and then all my samples were mostly 1's, and now I'm seeing more oscillation between these runs. So I've wired it up as RND_TYPE_UNKNOWN, not RND_TYPE_RNG (it will immediately flunk our rngtest and be disabled), and I estimated it to provide at most one bit of entropy per byte of data -- which may still be optimistic. I also added a sysctl node hw.sun8icryptoN.rng to read out 1024-byte samples for analysis, and I left the driver commented out in GENERIC64 for now. (If anyone has contacts at Allwinner who can tell us about how the alleged TRNG is supposed to work, please let me know!) Reduce some duplicated bus_dma clutter. Factor out some of the self-test logic used for debugging. Add missing bus_dmamap_sync(POSTWRITE) while here. Make sure ERESTART doesn't come flying out to userland. I picked ERESTART to mean `all channels are occupied' because that's what opencrypto(9) uses to decide whether to queue a request, but it's not appropriate for sysctl(2) to return that. Avoid a race between interruption and reacquisition of lock. Otherwise, we would have leaked the memory in this case. Tidy up comments. Oops -- forgot to kmem_free. Fix typo -- acknowledge interrupts _and_ errors. Reduce entropy estimate for sun8icrypto TRNG. NIST's SP800-90B entropy estimation tools put it at no more than .08 bits of entropy per byte of data(!), so estimate 100 bits of data per bit of entropy. This is probably not conservative enough -- the NIST tools were written without knowledge of how this alleged TRNG works! Knowledge of the physics of how the TRNG is supposed to work could probably enable a better job at predicting the outputs. While here, bump the size of data we can sample directly with sysctl to 4096 bytes. Enable sun8icrypto in GENERIC64. But set its entropy estimate to zero until we have a better idea of how it works. Can't really hurt this way unless sun8icrypto is maliciously dependent on all other inputs to the entropy pool, which seems unlikely. Fix (presently harmless) psato. Don't overwrite cy_root_node; use cy_trng_node as intended. Fix previous brainfart. Don't use the uninitialized trng node as the root node -- derp. Instead, use the root node as the root node, and initialize the trng node here.
Merge changes from current as of 20200406
file sun8i_crypto.h was added on branch netbsd-9 on 2020-05-18 18:45:40 +0000
file sun8i_crypto.h was added on branch phil-wifi on 2020-04-08 14:07:31 +0000
Draft driver for Allwinner Crypto Engine. Found on, e.g., the Pinebook. Only used for TRNG at the moment, but hooking it up to opencrypto(9) shouldn't be too hard if anyone still cares about that these days. The distribution of the alleged TRNG is very nonuniform distributed seems to alternate between toward runs with exceptionally high fractions of 0 bits and runs with exceptionally high fractions of 1 bits -- initially all my samples were mostly 0's, and then all my samples were mostly 1's, and now I'm seeing more oscillation between these runs. So I've wired it up as RND_TYPE_UNKNOWN, not RND_TYPE_RNG (it will immediately flunk our rngtest and be disabled), and I estimated it to provide at most one bit of entropy per byte of data -- which may still be optimistic. I also added a sysctl node hw.sun8icryptoN.rng to read out 1024-byte samples for analysis, and I left the driver commented out in GENERIC64 for now. (If anyone has contacts at Allwinner who can tell us about how the alleged TRNG is supposed to work, please let me know!)