[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef2f6e41-bf9e-470e-a416-fda7ce5d8a51@kabelmail.de>
Date: Mon, 23 Sep 2024 09:48:54 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: linux.amoon@...il.com
Cc: Jason@...c4.com, clabbe@...libre.com, heiko@...ech.de,
herbert@...dor.apana.org.au, hl@...k-chips.com,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, mike.rudenko@...il.com,
robin.murphy@....com, shawn.lin@...k-chips.com, troy.lin@...k-chips.com,
ty@...s.org
Subject: Re: [PATCH] hw_random: rockchip: import driver from vendor tree
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
Powered by blists - more mailing lists