From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FDC82248AE for ; Wed, 26 Nov 2025 18:36:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764182162; cv=none; b=EXA88BWZzCmLs427m7LcaM6KZXfI0evTZ2/FLEykh9NUxtXI2OTqknTWXxFAvg1tfwWAoCucD6Gt3xlPsmECRfALTkkXKY6xnZ+JiRqv6L/DLq9yAOrPNOUDX+4bUET3hYSkguNQm5RD4aSOMMWzqZ0TJmKtGEg77OI+lezXWW8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764182162; c=relaxed/simple; bh=l+UpyQQXX4ETUL7fz0/4jQ9/53R6ELtNZ9Z4xa9EpMc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=QuWK1AAhyG2vdcK1dz2UnHwpN82kmAXzHQ6hAkyzulQDNwB2H4Fcnh00fWLIea3V/nas0kS/jezD417zm3MwvOh+g7ZkHe6cq2Mcs051C41gqRKOkbET3VKanySmsqjTmn/154bS27vVeNK18RdqjC9LFlLOYO+DdZnaPrlzarY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jPzA5Cqh; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jPzA5Cqh" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-42bb288c1bfso70883f8f.2 for ; Wed, 26 Nov 2025 10:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764182160; x=1764786960; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=l+UpyQQXX4ETUL7fz0/4jQ9/53R6ELtNZ9Z4xa9EpMc=; b=jPzA5Cqhmrbfgc+zL534Z/H4GkxyfEnDr5gk+XEtyfYWXbd+sNtIcjHRihNUVz+9iY aM2Ah74wPTlcsiwgq6Z+FdZX3PS8PHm/Tp0t0vxz04YXWFEBofXKZzGx40LVw69icnrU gp/R3C/D+FWBYLF8QzdiGSMID3CVCdlMoRjQfqOUHdVXpMCj1OaKmfiWPDOpHZz1YQDE UMa4jcnYqp+9pBydFtdJRURgQA0VHaIsx+bE2lgNyh5FVcsqqfxKYXFG4UDufxOa9JQC +dRGEdOG6cN9UWscoSOXbAyE0Fr8pw3Txged50rigpp0lVKV/GTggOXVpBV4kBEyIlFJ 9bFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764182160; x=1764786960; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=l+UpyQQXX4ETUL7fz0/4jQ9/53R6ELtNZ9Z4xa9EpMc=; b=lYBk7/BYBC6w/8KK/jFn+nHQQaDm2UpAN1X4uGSgeMC0fClvs0leTJOcrQA4k9ppi5 swPul53J8QPhNIMmp0ZylLbGnptoZ5ollj4Jt9/MXWtyTL+Xd5lTQ3ZT74MqpRRr2Pwd 9w6JGeJu+x8OUhu1DVZVnwdbLzS1MuNj6TyJkEblnPQNlJKE++aIkIM1v1jJoCiWs5bh JFH+BRE3sWIIXZ4URGRPUcSUAcQfOvalOG9fXWkMT/7SsXhFcRjoedVVXJB2kS9JAxtD RVmfIAtHQlNd4xEXEw7PiXCFOhMyrdkp1tLrI7UTNuWhpTe8DxRtEhWowhDpEb9j23un cX3g== X-Forwarded-Encrypted: i=1; AJvYcCWAUw4c8O8OEy9bg6iEdbItQetcA9mveZlyi0tRczLX3GT+e/OFaZTrJUcrMKjHvkXbUqmfyhYv+P7eNGo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0Q7CF6i5u020Z80JYUl/1jqGW5hgflOjMsZZJgCijpcMagxQ3 HDWmC/0+AvClnH05hQPR7qfzyyJ+r4k7mcekO9ngfXIpBlbC8h517b0+ X-Gm-Gg: ASbGncsvVmjKZyhOaibACWslLRgieSMG/7LmboHVC8tQoZLwU8MDfv1ScPWffrJxkAt rQC+X1zShCW7F4rrfxjAiv23cPcAKdyi7cU01hvVNpqq9/mtP4kwkmuoKwA4/hxAvLHuPMVP2fl wX5T4NJw/zJdO2Xe15lpBL8x0Hy4RyiBEgWs+T+ZYEobcSkybtw8ccsT/S3rhsLqeTq4c4vZgdo GbfB9f4z0x/KyMESRMqnAyV1sudFk6+2KGWJqDS8nev05mhsW5yLiX5of9Bqqq9mkgH04Ie7GYK 4dyrd6P/4CQ3Cj4s0mpXODzkEitSDgtLR4ewddEa0DS01DvxberF8dikRyMjBPMfdYLzTp/Dshw g3TNZjqA24kFo8EMOA7tdbIKUct9cvOzN9i8TzDpW+cbbZ8Vw300S8ahnmdd/FCaNT2XWvl9TMS Ehfj8Cd3t+sQ7zxwDuQp6Y45NQMGwrpSEm9g== X-Google-Smtp-Source: AGHT+IEDaKLHkuJUlFxjTNYKXYKXILgs49wv90DIhz+B7Erbl6ou89i0ju5Aozc3Dud2Eq5F+/QLtQ== X-Received: by 2002:a05:6000:401f:b0:42b:2ac7:7942 with SMTP id ffacd0b85a97d-42e0f1e3433mr8676095f8f.5.1764182159355; Wed, 26 Nov 2025 10:35:59 -0800 (PST) Received: from vitor-nb.Home (bl19-170-125.dsl.telepac.pt. [2.80.170.125]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42cb7fa3a6bsm41766947f8f.28.2025.11.26.10.35.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Nov 2025 10:35:58 -0800 (PST) Message-ID: <82e78d56c7df6e1f93de29f9b3a70f7c132603c4.camel@gmail.com> Subject: Re: CAAM RSA breaks cfg80211 certificate verification on iMX8QXP From: Vitor Soares To: Ahmad Fatoum , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev Cc: horia.geanta@nxp.com, pankaj.gupta@nxp.com, gaurav.jain@nxp.com, herbert@gondor.apana.org.au, john.ernberg@actia.se, meenakshi.aggarwal@nxp.com Date: Wed, 26 Nov 2025 18:35:57 +0000 In-Reply-To: <3d44957f-8c09-47f3-93e0-78a1d34adfd0@kernel.org> References: <3d44957f-8c09-47f3-93e0-78a1d34adfd0@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2025-11-26 at 13:59 +0100, Ahmad Fatoum wrote: > Hello Vitor, >=20 > On 26.11.25 11:55, Vitor Soares wrote: > > ++imx@lists.linux.dev > >=20 > > On Mon, 2025-11-24 at 19:03 +0000, Vitor Soares wrote: > > > I=E2=80=99m currently investigating an issue on our Colibri iMX8QXP S= oM running > > > kernel > > > 6.18-rc6 (also reproducible on v6.17), where cfg80211 fails to load t= he > > > compiled-in X.509 certificates used to verify the regulatory database > > > signature. > > >=20 > > > During boot, I consistently see the following messages: > > > =C2=A0cfg80211: Loading compiled-in X.509 certificates for regulatory= database > > > =C2=A0Problem loading in-kernel X.509 certificate (-22) > > > =C2=A0Problem loading in-kernel X.509 certificate (-22) > > > =C2=A0cfg80211: loaded regulatory.db is malformed or signature is > > > missing/invalid > > >=20 > > > As part of the debugging process, I removed the CAAM crypto drivers a= nd > > > manually > > > reloaded cfg80211. In this configuration, the certificates load corre= ctly > > > and > > > the regulatory database is validated with no errors. > > >=20 > > > With additional debugging enabled, I traced the failure to > > > crypto_sig_verify(), > > > which returns -22 (EINVAL). > > > At this stage, I=E2=80=99m trying to determine whether: > > > =C2=A0- This is a known issue involving cfg80211 certificate validati= on when > > > the > > > CAAM > > > hardware crypto engine is enabled on i.MX SoCs, or > > > =C2=A0- CAAM may be returning unexpected values to the X.509 verifica= tion > > > logic. > > >=20 > > > If anyone has encountered similar behavior or can suggest areas to > > > investigate=E2=80=94particularly around CAAM=E2=80=94I would greatly = appreciate your > > > guidance. > > >=20 > > > Thanks in advance for any insights, > > > V=C3=ADtor Soares > >=20 > > Following up with additional debugging findings. > >=20 > > I traced the -EINVAL to rsassa_pkcs1_verify() in the PKCS#1 v1.5 > > verification > > path. The check that fails expects a leading 0x00 byte in the RSA outpu= t > > buffer. > > To investigate further, I poisoned the output buffer with 0xAA before t= he > > RSA > > operation. CAAM RSA operation returns success, but the output buffer is > > never > > written to. > >=20 > > During debugging, I loaded cfg80211 multiple times and observed that > > sporadically one of the certificates gets verified correctly, but never > > both. > >=20 > > I confirmed that other CAAM operations work correctly by testing hwrng = via > > /dev/hwrng, which produces valid random data. > >=20 > > Given that CAAM reports success but does not populate the RSA output bu= ffer, > > the > > problem appears to be somewhere in the RSA execution flow (possibly in = how > > the > > result buffer is handled or returned), but I don=E2=80=99t have enough = insight into > > CAAM's RSA implementation or firmware interaction to pinpoint the exact > > cause. > >=20 > > As noted previously, blacklisting caam_pkc to force rsa-generic resolve= s the > > issue. >=20 > Just a shot in the dark, because I have no experience with i.MX8 beyond > i.MX8M: >=20 > Is the CAAM cache-coherent on your SoC? If so does the DT specify dma-coh= erent > as it should? On i.MX8M, it's not cache-coherent, but on Layerscape it wa= s and > the mismatch with the DT leads to symptoms matching what you are observin= g. >=20 Thanks for the suggestion. I tested with dma-coherent added to the CAAM and= job ring nodes but the issue persists. I traced through the DMA path in caampkc.c and confirmed: - dma_map_sg() is called in rsa_edesc_alloc() with DMA_FROM_DEVICE - dma_unmap_sg() is called in rsa_io_unmap() from rsa_pub_done() before completion - CAAM returns status err=3D0x00000000 (success) - dst_nents=3D1=20 Yet the output buffer remains untouched (still contains my 0xAA poison patt= ern). The kernel DMA handling appears correct. CAAM accepts the job and reports success, but never writes the RSA result. Given that CAAM reports success b= ut does not populate the RSA output buffer, the problem appears to be somewher= e in the RSA execution flow (possibly in how the result buffer is handled or returned), but I don't have enough insight into CAAM's RSA implementation. > Off-topic remark: If you have performance comparison between running with= and > without CAAM RSA acceleration, I'd be interested to hear about them. > At least for the hashing algorithms, using the Cortex-A53 (+ CE) CPU was = a lot > faster than bothering with the CAAM "acceleration". >=20 I haven't done a kernel-level CAAM vs software RSA comparison, but OpenSSL = with ARM Crypto Extensions shows ~3100 verify ops/sec and ~80 sign ops/sec for R= SA 2048 on the Cortex-A35. Regards, V=C3=ADtor