Message ID | 20221013184026.63826-1-markus.stockhausen@gmx.de |
---|---|
Headers | show |
Series | crypto/realtek: add new driver | expand |
Am Donnerstag, dem 13.10.2022 um 20:40 +0200 schrieb Markus Stockhausen: > This driver adds support for the Realtek crypto engine. It provides > hardware > accelerated AES, SHA1 & MD5 algorithms. It is included in SoCs of the > RTL838x > series, such as RTL8380, RTL8381, RTL8382, as well as SoCs from the > RTL930x > series, such as RTL9301, RTL9302 and RTL9303. Some little endian and > ARM based > Realtek SoCs seem to have this engine too. Nevertheless this patch > was only > developed and verified on MIPS big endian devices. > > Module has been successfully tested with > - lots of module loads/unloads with crypto manager extra tests > enabled. > - openssl devcrypto benchmarking > - tcrypt.ko benchmarking > > ... > > Markus Stockhausen (6) > crypto/realtek: header definitions > crypto/realtek: core functions > crypto/realtek: hash algorithms > crypto/realtek: skcipher algorithms > crypto/realtek: enable module > crypto/realtek: add devicetree documentation > > /devicetree/bindings/crypto/realtek,realtek-crypto.yaml| 51 + > drivers/crypto/Kconfig | 13 > drivers/crypto/Makefile | 1 > drivers/crypto/realtek/Makefile | 5 > drivers/crypto/realtek/realtek_crypto.c | 472 > ++++++++++ > drivers/crypto/realtek/realtek_crypto.h | 325 ++++++ > drivers/crypto/realtek/realtek_crypto_ahash.c | 406 > ++++++++ > drivers/crypto/realtek/realtek_crypto_skcipher.c | 361 +++++++ > 8 files changed, 1634 insertions(+) Hi (Herbert), as I got neither positive nor negative feedback after your last question I just want to ask if there is any work for me to do on this series? Thanks in advance. Markus
On Mon, Dec 05, 2022 at 07:47:59PM +0100, Markus Stockhausen wrote: > > as I got neither positive nor negative feedback after your last > question I just want to ask if there is any work for me to do on this > series? Sorry about that. There is still an issue with your import function. You dereference the imported state directly. That is not allowed because there is no guarantee that the imported state is aligned for a direct CPU load. So you'll either need to copy it somewhere first or use an unaligned load to access hexp->state. Cheers,
Am Dienstag, dem 06.12.2022 um 12:10 +0800 schrieb Herbert Xu: > On Mon, Dec 05, 2022 at 07:47:59PM +0100, Markus Stockhausen wrote: > > > > as I got neither positive nor negative feedback after your last > > question I just want to ask if there is any work for me to do on > > this > > series? > > Sorry about that. > > There is still an issue with your import function. You dereference > the imported state directly. That is not allowed because there is > no guarantee that the imported state is aligned for a direct CPU > load. > > So you'll either need to copy it somewhere first or use an unaligned > load to access hexp->state. > > Cheers, No problem, this is something I can work with. Nevertheless I'm unsure about your guidance. If I get it right, the state assignment is not ok. ... const struct rtcr_ahash_req *hexp = in; hreq->state = hexp->state; << *** maybe unaligned? *** if (hreq->state & RTCR_REQ_FB_ACT) hreq->state |= RTCR_REQ_FB_RDY; if (rtcr_check_fallback(areq)) return crypto_ahash_import(freq, fexp); memcpy(hreq, hexp, sizeof(struct rtcr_ahash_req)); ... Comparing this to safeexcel_ahash_import() where I got my ideas from one sees a similar coding: ... const struct safexcel_ahash_export_state *export = in; int ret; ret = crypto_ahash_init(areq); if (ret) return ret; req->len = export->len; << *** same here *** req->processed = export->processed; req->digest = export->digest; memcpy(req->cache, export->cache, HASH_CACHE_SIZE); memcpy(req->state, export->state, req->state_sz); ... Thanks in advance for your help.
On Tue, Dec 06, 2022 at 09:59:49AM +0100, Markus Stockhausen wrote: > > const struct rtcr_ahash_req *hexp = in; > > hreq->state = hexp->state; << *** maybe unaligned? *** Try const struct rctr_ahash_req __packed *hexp = in; This should tell the compiler to use unaligned accessors. > Comparing this to safeexcel_ahash_import() where I got my ideas from > one sees a similar coding: > > ... > const struct safexcel_ahash_export_state *export = in; This is equally broken unless that driver can only be used on platforms where unaligned access is legal (such as x86). Cheers,