Received: by 2002:a17:90a:88:0:0:0:0 with SMTP id a8csp256576pja; Fri, 22 Nov 2019 06:08:42 -0800 (PST) X-Google-Smtp-Source: APXvYqzpIeggLPOiAHHtDRVkQ2qsddyrARBzvrMNt9caSICl/c9tOjSg4ZTdnruV697OAHWoY4vn X-Received: by 2002:a17:906:e289:: with SMTP id gg9mr22257048ejb.71.1574431721921; Fri, 22 Nov 2019 06:08:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574431721; cv=none; d=google.com; s=arc-20160816; b=GzFnCGD+yzCH7mCHvYe5kbOtcHzLP3lkkXYn/LzqNVKX9bAd302XrjcGsx18a84FXC lqNcjqKV9A2jShzrP9/Uv5zWu6UtBpi5Vsz405n4pQZ13mMWfX6jKnID/jASx/cpEpdZ kPI5oY7D+JbL0ZIsdrlhVm1nR3XPMI/SpJ31KPd6t4VgZTdGtWOTbPyO/zTKTdQabGoj 5W+3D7yLvzbCsBNI3TzU4kBTIn9AkLtXYP1gRF2d8pd2FfzDqpkD0gneFA+vLe6B+Eh3 6exRK1iFgekKq/Q604qfhmwQ5DRtbLprpqsVutUM+Dg/dGZNxfc+r8/YieBdUrg+Acv7 8MjQ== 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=d2h0iowbT2trTHR6+AXliuYkybNFEEiP0X2JA8Gzzaw=; b=b26I13dgYA0Ofa8H9Ips7gp++2w0zNcQrgpTHLe6kcz8Dr6RDhxkH87KhJU3wG5hRt 0+d/NLciMHRxT1yKgKZU0CN99lnnh4X7S8lNq6rvv8jCizXk+TJUzuBAxmPuEsBr/J0Z ttYkXEWd9dr0Sdx2G1nXYdFXmS2nBzBKPIB8rr0eBzPQ+IXWiRq5HNnTWNOPZz6M1eOM //q05GYz9kUtbIq81vCn22g/OjBpXbnXb2PDH2abcNzuWq0lDjklEQV7K97xv0K2Agl/ e9dkC00JGqK+Bx7saUeU4RmkbyoeldCFTNsejGoDc1OwOfm6MpheaXD2hByOpv/hz/PJ LMeg== 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 e8si5344158edk.444.2019.11.22.06.08.05; Fri, 22 Nov 2019 06:08:41 -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 S1727777AbfKVOIA (ORCPT + 99 others); Fri, 22 Nov 2019 09:08:00 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:37828 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726046AbfKVOIA (ORCPT ); Fri, 22 Nov 2019 09:08:00 -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 1iY9bL-00028J-1W; Fri, 22 Nov 2019 22:07:59 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1iY9bJ-0002zv-Kp; Fri, 22 Nov 2019 22:07:57 +0800 Date: Fri, 22 Nov 2019 22:07:57 +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: <20191122140757.mbpnasimvnhke3k2@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> <20191122104259.ofodwadrgszdxuto@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 02:38:30PM +0100, Harald Freudenberger wrote: > > The pkey is in fact a encrypted key + a verification pattern for the > encrypted key used. It gets invalid when this encryption key changes. > The encryption key changes when the LPAR is re-activated so for > example on suspend/resume or an Linux running as kvm guest > gets relocated. So this happens very rarely. I see. Is there any way of you finding out that the key has been invalidated apart from trying out the crypto and having it fail? Ideally you'd have a global counter that gets incremented everytime an invalidation occurs. You can then regenerate your key if its generation counter differs from the current global counter. Also when the crypto fails due to an invalid key you're currently calling skcipher_walk_done with zero. This is wrong as the done function must be called with a positive value or an error. In some cases this can cause a crash in scatterwalk. IOW you should just repeat the crypto operation after regenerating the key rather than looping around again. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt