Received: by 2002:a17:90a:88:0:0:0:0 with SMTP id a8csp11564pja; Fri, 22 Nov 2019 02:46:50 -0800 (PST) X-Google-Smtp-Source: APXvYqw8fUxDItbaqH5fe5MT9ju86DoDyqEMD3rqwS3XmzfC93cTa56OcGH7XVCvZZmBT5DF6zzL X-Received: by 2002:a50:9269:: with SMTP id j38mr233681eda.5.1574419610185; Fri, 22 Nov 2019 02:46:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574419610; cv=none; d=google.com; s=arc-20160816; b=0M+/nZw5o+zSe2EpRw42kiOUc7aYZtoy0ZvTSl3dpVfEty4ieQ2F4x1TriZckC8IX3 LuGWnRTiLPdHYALIMppl5gRGtc3GRnSu12VDkEBmwSSAvI8B2zJydJ7mv+AJ1ov8Rd1B zKhD0K7ZJjKG3wqJNcQVcssj0wA/L7jB6QGr9DrHCdUjmTP+bFQv67flsN+HvesxsobZ aolRAEn/3AaIj7H489ySymLcb6d4M1pdemVgJ4YxkQ32lsPA1vEratMEJcEch90McCrW x4Hv//JMdXl4c2ap4HSLGfAmnST8/UsAHAdrzlZEM6nnMazhvva+M8G1F/8tZkKb0q7Y vt3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QUGdFwpK/3afdQM89MB4Z7xqAUe/tPuH/huR9kYU3bE=; b=whUpFn+vMfvcgalvxyIkF9/slgoatannDGdCuOiofD7THZ228FEc8ucoC3Dp9mI8mw 2w8kWHlXYO7x7/ysvDayCX82fYuo2OYW+h0VOAmBIC+4PmpyZjzzDruahcCw7WOPsL9M EcEbtrYMgWL9yVrCTnN0zy4B/7q/VgeX0fILuNJH0mI2QtdN5FhbEByRFfAa1tMcLuBl N5GvrMt/ADC1nt/0p3FBaCD5ff7eBerYeu93zSCXbk45F28kQEqBFE7u0e9gF16iYony OWmVnPmvMuxz/X1pdN9w+8YhRdbdL7OPRsY2NX5bInZ7BsFPkpxWb+ftqati3miJBSxR 3MRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w20si5019131edc.397.2019.11.22.02.46.23; Fri, 22 Nov 2019 02:46:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729178AbfKVKnD (ORCPT + 99 others); Fri, 22 Nov 2019 05:43:03 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:51570 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729172AbfKVKnC (ORCPT ); Fri, 22 Nov 2019 05:43:02 -0500 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1iY6Oz-0002gj-Oq; Fri, 22 Nov 2019 18:43:01 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1iY6Ox-0005Bf-UX; Fri, 22 Nov 2019 18:42:59 +0800 Date: Fri, 22 Nov 2019 18:42:59 +0800 From: Herbert Xu To: Harald Freudenberger Cc: linux-crypto@vger.kernel.org, ebiggers@kernel.org, heiko.carstens@de.ibm.com, gor@linux.ibm.com Subject: Re: [PATCH 2/3] s390/crypto: Rework on paes implementation Message-ID: <20191122104259.ofodwadrgszdxuto@gondor.apana.org.au> References: <20191113105523.8007-1-freude@linux.ibm.com> <20191113105523.8007-3-freude@linux.ibm.com> <20191122081338.6bdjevtyttpdzzwl@gondor.apana.org.au> <87e9dbee-4024-602c-7717-051df3ac644d@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87e9dbee-4024-602c-7717-051df3ac644d@linux.ibm.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Nov 22, 2019 at 10:54:50AM +0100, Harald Freudenberger wrote: > The setkey() sets the base key material (usually a secure key) to an > tfm instance. From this key a 'protected key' (pkey) is derived which > may get invalid at any time and may need to get re-derived from the > base key material. > An tfm instance may be shared, so the context where the pkey is > stored into is also shared. So when a pkey gets invalid there is a need > to update the pkey value within the context struct. This update needs > to be done atomic as another thread may concurrently use this pkey > value. That's all what this spinlock does. Make sure read and write > operations on the pkey within the context are atomic. > It is still possible that two threads copy the pkey, try to use it, find out > that it is invalid and needs refresh, re-derive and both update the pkey > memory serialized by the spinlock. But this is no issue. The spinlock > makes sure the stored pkey is always a consistent pkey (which may > be valid or invalid but not corrupted). OK. Can you give me a bit more background info on how often this is likely to happen? I mean it happened every time you might as well not store the protected key in the tfm at all. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt