Le Mon, Sep 23, 2024 at 09:48:54AM +0200, Janpieter Sollie a écrit : > > Hi everybody, > > Is there any chance this random driver will be upstreamed? > I'm using it instead of the built-in crypto driver (rk3328-crypto), as this crypto driver showed > the following: > > > [ 9.270549] rk3288-crypto ff060000.crypto: will run requests pump with realtime priority > > [ 9.270687] rk3288-crypto ff060000.crypto: Register ecb(aes) as ecb-aes-rk > > [ 9.270808] rk3288-crypto ff060000.crypto: Register cbc(aes) as cbc-aes-rk > > [ 9.270831] rk3288-crypto ff060000.crypto: Register ecb(des) as ecb-des-rk > > [ 9.270848] rk3288-crypto ff060000.crypto: Register cbc(des) as cbc-des-rk > > [ 9.270864] rk3288-crypto ff060000.crypto: Register ecb(des3_ede) as ecb-des3-ede-rk > > [ 9.270880] rk3288-crypto ff060000.crypto: Register cbc(des3_ede) as cbc-des3-ede-rk > > [ 9.270896] rk3288-crypto ff060000.crypto: Register sha1 as rk-sha1 > > [ 9.270915] rk3288-crypto ff060000.crypto: Register sha256 as rk-sha256 > > [ 9.270932] rk3288-crypto ff060000.crypto: Register md5 as rk-md5 > > so the options here are pretty useless: > standard tls / ssh (ktls anyone?) almost never uses ecb or cbc ciphers, and about des ... yeah, > won't dig into that one. > I think a rk3328 device will actually benefit more from a entropy source (even if it's not > high-quality) than from sha1/256 which are almost always covered by armv8 crypto extensions. > I tried this patch (and disabled the crypto device in dts), it works. > Off course there are FIPS failures, but the user employing a rk3328 board probably knows this is > not a high-security device. > > Any chances here? applying the patch on 6.6.48 (even with clang thinLTO) works flawlessly. > > kind regards, > > Janpieter Sollie Did you test if it really works by testing entropy output QUALITY ? I asked how the serie was tested and the sender never answered raising a big red flag. If you check the thread, someone tested and the quality bringed by the vendor driver is really BAD. This is due to the fact that their sample value was really too short. So as-is, this serie is a security issue to the randomness quality. I need to regrab some time finishing, my patch adding support for it on intree crypto driver. I found an old tree that I push here https://github.com/montjoie/linux/tree/rk3288-trng This is not a final patch, but it could help finding a correct value of sample via the debugfs. I dont remember which value of sample was necessary to obtain a minimal quality. (perhaps 500 since it seems the default in my patch). Unfortunatly, I cannot test it immediatly, as my CI controller got some HW issue, and I need to fix them. Regards
