linux-kernel - Re: [PATCH] crypto: caam: blob_gen.c: warn if key is insecure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 7 Nov 2022 08:44:55 +0100 (CET)
From:   Nikolaus Voss <nv@...n.de>
To:     Herbert Xu <herbert@...dor.apana.org.au>
cc:     Horia Geantă <horia.geanta@....com>,
        Pankaj Gupta <pankaj.gupta@....com>,
        Gaurav Jain <gaurav.jain@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        David Gstir <david@...ma-star.at>,
        Steffen Trumtrar <s.trumtrar@...gutronix.de>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jarkko Sakkinen <jarkko@...nel.org>
Subject: Re: [PATCH] crypto: caam: blob_gen.c: warn if key is insecure

On Fri, 4 Nov 2022, Herbert Xu wrote:
> On Wed, Oct 19, 2022 at 02:44:56PM +0200, Nikolaus Voss wrote:
>>
>> @@ -62,11 +63,13 @@ int caam_process_blob(struct caam_blob_priv *priv,
>>  		      struct caam_blob_info *info, bool encap)
>>  {
>>  	struct caam_blob_job_result testres;
>> +	const struct caam_drv_private *ctrlpriv;
>
> Please keep the declarations sorted by length in reverse.

ok!

>
>> @@ -100,6 +103,11 @@ int caam_process_blob(struct caam_blob_priv *priv,
>>  		goto out_unmap_in;
>>  	}
>>
>> +	ctrlpriv = dev_get_drvdata(jrdev->parent);
>> +	moo = FIELD_GET(CSTA_MOO, ctrlpriv->ctrl->perfmon.status);
>> +	if (moo != CSTA_MOO_SECURE && moo != CSTA_MOO_TRUSTED)
>> +		dev_warn(jrdev, "using insecure test key!\n");
>
> Who is the audience of this warning? Is it possible for this warning
> to be too frequent?

The warning is issued every time the non-volatile hardware test key is 
used to seal/unseal data. This way, the association to the operation is 
strong and is less likely to be ignored by mistake. Further, the system 
security monitor can transition to a non-secure state any time, so one 
warning during boot-up doesn't suffice. IMO, on a typical system, the 
warning occurs with very low frequency, only a few times during 
e.g. authenication or mounting of encrypted volumes.

The audience is the developer who forgets to enable secure boot (HAB) or 
even doesn't know she has to enable HAB to employ the device's unique 
hardware key instead of the test key.

Niko