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;
Subject: Re: [PATCH 2/3] s390/crypto: Rework on paes implementation
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org, ebiggers@kernel.org,
        heiko.carstens@de.ibm.com, gor@linux.ibm.com
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>
 <bd21bf85-7bfc-afd6-270b-272bd0fa553a@linux.ibm.com>
 <20191122140757.mbpnasimvnhke3k2@gondor.apana.org.au>
From:   Harald Freudenberger <freude@linux.ibm.com>
Date:   Fri, 22 Nov 2019 15:45:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191122140757.mbpnasimvnhke3k2@gondor.apana.org.au>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Message-Id: <dbd99075-22d3-b41a-57c6-ba85168eab87@linux.ibm.com>
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On 22.11.19 15:07, Herbert Xu wrote:
> 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?
No. By using the pkey for a crypto operation the hardware
checks the verification pattern and if there is a mismatch
it simple rejects the operation. Theoretically such an operation
can only partly complete and then a pkey could get invalid.
I have no way to check if the pkey is still valid before the
cpacf instruction call.
>
> 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.
That's right. I'll try to rework the functions this way to
avoid calling skciper_walk_done with 0.

Thanks
>
> Cheers,