From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93AEB36F435 for ; Tue, 17 Mar 2026 11:20:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773746442; cv=none; b=nkLubtVtDlFvXdVnJF2Me1uWYPg/kFbyi5Yxj1Fk1RzDJr6yQqPvxA1mwo+Kcq8X21mOyWAZjJzgP/bIiBUrAjO2NBQDzXUuh3JKwJ+eFlYJfFx0Z2hNMeV/QtpBk6Y7kCtUiW3W4e67jcLs4BnqUdPnzp9fv1fu3Xd6OyJIwJo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773746442; c=relaxed/simple; bh=pOAJ7gTT2gW3rIbyM1AFAzko/De87b7KJmIKhZOX4RU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I94G0fiKcPGQhAOEfMHGe2UfMYJLFIHxAZe1z3jB2R3IevDWOxP8OzOpS0MARdEWWxUYepFQfOWkiwOmX3PSqSlOeFTinTl0uFei7I0geOcCwwBwRrIo8oHMTBldJfZiKI5icg6Znq/UODKIrzQO1iuYMX+yjWDWANn3r5wgFK0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=au04Iwaq; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="au04Iwaq" Date: Tue, 17 Mar 2026 12:20:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773746438; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fJ19JX+Fdfvgr+LNxpY/TOqvYP2YRwuZtSMmPJ3oyp4=; b=au04IwaquZL/9L402rl9GkDbdHPdZDGzWMebJ8y0SVeq0gIrOG8fHY5jnHIxEQdMGRFUAF Y2G10qY+H+5rOpeTEUsauUiBKBmfmyLqtIXq+EZ+34p0RmM33EGevjqIHUE/R6W8RzV+OQ XOYEeugQEjPKVe+Vg4leqmT42xtW7qA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Thorsten Blum To: Herbert Xu Cc: Horia =?utf-8?Q?Geant=C4=83?= , Pankaj Gupta , Gaurav Jain , "David S. Miller" , Kim Phillips , Yuan Kang , stable@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] crypto: caam - remove HMAC key hex dumps from hash_digest_key Message-ID: References: <20260306111204.302544-1-thorsten.blum@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On Sat, Mar 14, 2026 at 01:56:25PM +0900, Herbert Xu wrote: > On Fri, Mar 06, 2026 at 12:12:03PM +0100, Thorsten Blum wrote: > > Stop dumping sensitive HMAC key bytes (original and reduced keys) in > > hash_digest_key() to avoid leaking secrets when debug logging is > > enabled. > > > > Fixes: 045e36780f11 ("crypto: caam - ahash hmac support") > > Fixes: 3f16f6c9d632 ("crypto: caam/qi2 - add support for ahash algorithms") > > Cc: stable@vger.kernel.org > > Signed-off-by: Thorsten Blum > > --- > > drivers/crypto/caam/caamalg_qi2.c | 5 ----- > > drivers/crypto/caam/caamhash.c | 6 ------ > > 2 files changed, 11 deletions(-) > > What is the rationale for this? When debugging is enabled, all > sorts of things could be dumped, e.g., passwords. This is not specifically about caam, but (debug) logging of potentially sensitive key material should generally be avoided, imho. Some other recent examples: https://lore.kernel.org/lkml/20260227230008.858641-2-thorsten.blum@linux.dev/ https://lore.kernel.org/lkml/20260303132552.65235-2-thorsten.blum@linux.dev/ https://lore.kernel.org/lkml/20260303190350.78705-2-thorsten.blum@linux.dev/ > Is there a scenario where production systems will run with debugging > enabled in caam? I don't know - possibly. Thanks, Thorsten