Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Ard Biesheuvel <ardb@kernel.org>,
        David Howells <dhowells@redhat.com>
CC:     Herbert Xu <herbert@gondor.apana.org.au>,
        Scott Mayhew <smayhew@redhat.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: RPCSEC GSS krb5 KUnit test fails on arm64 with h/w accelerated
 ciphers enabled
Thread-Topic: RPCSEC GSS krb5 KUnit test fails on arm64 with h/w accelerated
 ciphers enabled
Thread-Index: AQHZcwlyVC5Tj4/bTUCg0bPZoyBbT69Ahe0AgAADmoCAADLHAIAANVOAgAACVIA=
Date:   Fri, 28 Apr 2023 16:18:17 +0000
Message-ID: <870429E7-8202-405B-96F7-46A11B41EF05@oracle.com>
References: <ZEBi8ReG9LKLcmW3@aion.usersys.redhat.com>
 <ZEuVcizjPtG96/ST@gondor.apana.org.au>
 <CAMj1kXGOxw2mm8dVNHBg3HfJ7==JVV+vdXaW3iGGKamb4ZAg-g@mail.gmail.com>
 <F46EA3E0-1338-4E92-8CCF-DD869BD573BE@oracle.com>
 <CAMj1kXE29dMSgjkDPUXf0LFnxyrMeSO5NxG8fjYCuG=HJJ7wiA@mail.gmail.com>
In-Reply-To: <CAMj1kXE29dMSgjkDPUXf0LFnxyrMeSO5NxG8fjYCuG=HJJ7wiA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?onyvRNudZaVJCYVCRicPb6zbhFIRsD7KpFRKNGKOzqHjKQ+tUNClNRt2ctY/?=
 =?us-ascii?Q?+giIWrk4D2tDU6Ck6mplFOjcZXeJrKNCq8W5eLs5CzWuFKfpOrlFqpEbl2cu?=
 =?us-ascii?Q?9xDreiC/fIQrGapM8nR6VMl1OOf95S+acn3gMayO0emc4+504VimS4UNSbnW?=
 =?us-ascii?Q?s5ZjbhNCzj5snBkPbMRVg16/a+LSZL9mHlbwCmX4K+h9j3cuaJ2gt1IRBdN5?=
 =?us-ascii?Q?lJjHmVTldOZmJ198WN85SnJIAI+SewivoZONJEZgMBAk6HnIlSG7ymndhMHe?=
 =?us-ascii?Q?LML6pqTRItIC0COioHNskoytvj0bJD6t0DkVBLk8FSM0F+BSAsvFMFeeNZk5?=
 =?us-ascii?Q?1fZdPE3qVYbj+5CKYB100wp5V6avA0ODu8LW2bqcafWDwDBy38rPZaeTTU8h?=
 =?us-ascii?Q?Aw4Ujbz7sGJXusY7iUakBBIWjv+PRRkibJX2K+4MADM6PEi8tfIOJPsG2ASk?=
 =?us-ascii?Q?U/fxT1sI8KMiQ5R4RYRez/wFNpWb+CGuftsrkonzFQU83WHp6aiqocm1pste?=
 =?us-ascii?Q?ZMk6ktLUk0TTUQCWjM+kC7gaucwitGDUsqAGGfuG3Kqt8OT4v07VKZVGDMJs?=
 =?us-ascii?Q?q9H7eAkSmaIFOtzkcX4KkQedAzKlYHT3J3bgzM/Z4B/W1JQ2N07yYo2cSuKA?=
 =?us-ascii?Q?l6ObLKdxWKr3omP5u9l5v5MhSqOs/x8oN7nKPsruvO5BoV1BhcqQxbXKOZM1?=
 =?us-ascii?Q?UxmVT7iSPsc5i+dYcf95V/TDvUChl7ndyEcDRcURrdEpgPc/Ot6vKp5nWbbH?=
 =?us-ascii?Q?vOW5ByuI3qJXq53HaHXCFtlz9xKX1GGSMqc18brhC+UeXtAZmVY5lR1jilYg?=
 =?us-ascii?Q?g4WJ3br/GTcI/Fh+SJBvZxlZXAFNpZLwBxSxY9dr+S60VlAEdTf/4d2zbnF6?=
 =?us-ascii?Q?1ITl0982Ydg8QglWfYk/ZzoA6bD0GhSB2ZPmoIozi7egdSfg2Muu16aIQD0L?=
 =?us-ascii?Q?A7bSoiJsXW+HYnHUui0j9SzdtA5msM2yvH36YJ+ZghhEtjAXjOADxyKYe0WD?=
 =?us-ascii?Q?rrU/8arv7v2+S5Gfe3GeMp9xrtOQ3C9fe/uwV0FiHlspSmFNYEPMqIT25HuH?=
 =?us-ascii?Q?A/JvuomCO9O+XgtGxDE0QEZmQIRvlCRxFHsrekMXg0Ly20iO01pYmcMpVNlf?=
 =?us-ascii?Q?dEc3jO7qYG1U7LqFUY27rCHmIX3jBB8kw+F9sFo8hQZXvmzL9F7/ZOw2Zqsz?=
 =?us-ascii?Q?4GX2gBnHnKBc6H6FQNOMXi4YxBnZUxLnbc9rnNFDXCAeFkdITteYGM1Tb8hJ?=
 =?us-ascii?Q?DwrCIMucYZdokPIggdNWQ/hiU+3sX81KB9/jK8i5T/gSVyDsUWN+0ioqpqer?=
 =?us-ascii?Q?6++2/LeUUdDgkZ+fF24tZFhbPqFHwrspweB5dshvtITBeiZwZZccy+Em6t0r?=
 =?us-ascii?Q?TJXP1JXx6boxpoqLM+AXWSL8K6x4levENWgBuws2xmZ/fjxYRxI0r1s9PJfs?=
 =?us-ascii?Q?V6dOf5BoY0xx0Hs8YOH76w0A1oNcfy0eo69AItWoa+0glBELxInbwncJDbwt?=
 =?us-ascii?Q?F36i9VPy58tq7/w5nZqYYw+pRb0GqaTKyZMwe2eyJBzALrg3ZTpLnAcvM1ip?=
 =?us-ascii?Q?LZeRXQoR+NkmUPY01/LMb67qPpmQmEcTw9PCGgCTBUk9lyW8CjH5GGg0fbzZ?=
 =?us-ascii?Q?9A=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0728A39148C738499920AE5F2225C44F@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 1lukRPXP3BGkp7cMIp5aAbn8dggJEwSQhvQnt52sIt5ksskHwS8DGzw1M8/D+xvhIkThWHYgEp/a8vM52o5WIOvgIUgpu+MhgL4TlNtst9hOBiUDHMHQyvX1cMtkEDz8pHSjY7ilqYvgrtujOUCCO8eqom7D33RKR0xT93lXTqqOMKVwjrgYEsJsULZ70uBRMFjpMiarxzjiMSoVIcx1tKnIvLv3oTQR3DGOepebUFFxQgkvwxur216C4BWHdNyeVj/EL/b/llx66huMeh7exNSjV197KxgE4i/cBIhK7jPuzv0VDJxE+s4scXuewlwAS2JQmZlze1k4YWl18hBHumFIOsPJ5aPk/Xhd0xTz59xs3o5piTFriFZ8oSZbxqAGhAkB7iymDhuqf+pQS5zjywR8L8vKmMirgotq4ULb4NHvyBMzOvzDyERC0SZxEvaYBT8PL99k9hUVuHumLZYGNHvYG1nNxjnEDeBdiiKnp2HAJuP1g+JEHdOlZlGRiRagwqmiJFmi7T9K0Gapmtw79mssMjDvYZRGZvr+E4sx8CSe8Y+5Pv1UhL8jjohuFH//r6cyokjxo+u4OW5jaM3cqpSI9oWNm4ziiNLOnEq5kvNhBWMjpy1jgUbqDYF5FcQQHHniPrR36eSOuHKo/cH9sScjYyGu/ixxT5oRwH5AvOacq0AFZH99NOTcsnozkxj59dFvsEGgyqvWNmEDN2St7VBL9Wv97fGals28F0WgeiecRj/+1BBaVMyHODlU/qh0SW/7ClYhwecO+RBnINTHMP/D2rYdkZ9nEW9yit0SZ79smJduIe97u2Xmpp8Xj2j5GAflcrHqNrhzQ1CfUH4kqsrdibDrLzhrQyfxAcvyHWUYIer2gWzmCJ+eC8Q7eQYR
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 646adbc5-3baa-444b-d53f-08db48042cf6
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2023 16:18:17.4296
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OoJjOhPZx+PeJUIDJqKWmcXWqRCqgnXy7jVMFKDjkke9JUaEo1Y9Iy3xxQG4/t/r6CZHbMmF0kBHF44G1OMO4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7241
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-04-28_04,2023-04-27_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 bulkscore=0
 mlxlogscore=999 malwarescore=0 mlxscore=0 spamscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000
 definitions=main-2304280132
X-Proofpoint-GUID: Oi8BAL7yGozj4ASAR11bjHwXLFV4NDic
X-Proofpoint-ORIG-GUID: Oi8BAL7yGozj4ASAR11bjHwXLFV4NDic
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Apr 28, 2023, at 12:09 PM, Ard Biesheuvel <ardb@kernel.org> wrote:
>=20
> On Fri, 28 Apr 2023 at 13:59, Chuck Lever III <chuck.lever@oracle.com> wr=
ote:
>>=20
>>=20
>>=20
>>> On Apr 28, 2023, at 5:57 AM, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>=20
>>> On Fri, 28 Apr 2023 at 10:44, Herbert Xu <herbert@gondor.apana.org.au> =
wrote:
>>>>=20
>>>> Scott Mayhew <smayhew@redhat.com> wrote:
>>>>>=20
>>>>> diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-mo=
des.S
>>>>> index 0e834a2c062c..477605fad76b 100644
>>>>> --- a/arch/arm64/crypto/aes-modes.S
>>>>> +++ b/arch/arm64/crypto/aes-modes.S
>>>>> @@ -268,6 +268,7 @@ AES_FUNC_START(aes_cbc_cts_encrypt)
>>>>>      add             x4, x0, x4
>>>>>      st1             {v0.16b}, [x4]                  /* overlapping s=
tores */
>>>>>      st1             {v1.16b}, [x0]
>>>>> +       st1             {v1.16b}, [x5]
>>>>>      ret
>>>>> AES_FUNC_END(aes_cbc_cts_encrypt)
>>>>>=20
>>>>> But I don't know if that change is at all correct! (I've never even
>>>>> looked at arm64 asm before).  If someone who's knowledgeable about th=
is
>>>>> code could chime in, I'd appreciate it.
>>>>=20
>>>> Ard, could you please take a look at this?
>>>>=20
>>>=20
>>> The issue seems to be that the caller expects iv_out to have been
>>> populated even when doing ciphertext stealing.
>>>=20
>>> This is meaningless, because the output IV can only be used to chain
>>> additional encrypted data if the split is at a block boundary. The
>>> ciphertext stealing fundamentally terminates the encryption, and
>>> produces a block of ciphertext that is shorter than the block size, so
>>> what the output IV should be is actually unspecified.
>>>=20
>>> IOW, test cases having plain/ciphertext vectors whose size is not a
>>> multiple of the cipher block size should not specify an expected value
>>> for the output IV.
>>=20
>> The test cases are extracted from RFC 3962 Appendix B. The
>> standard clearly expects there to be a non-zero next IV for
>> plaintext sizes that are not block-aligned.
>>=20
>=20
> OK, so this is the Kerberos V specific spec on how to use AES in CBC
> mode, which appears to describe how to chain multiple CBC encryptions
> together.
>=20
> CBC-CTS itself does not define this: the IV is an input only, and the
> reason we happen to return the IV is because a single CBC operation
> may be broken up into several ones, which can only be done on block
> boundaries. This is why CBC-CTS itself passes all its tests: a single
> CBC-CTS encryption only performs ciphertext stealing at the very end,
> and the next IV is never used in that case. (This is why the CTS mode
> tests in crypto/testmgr.h don't have iv_out vectors)
>=20
> Note that RFC3962 defines that the penultimate block of CBC-CTS
> ciphertext is used as the next IV. CBC returns the last ciphertext
> block as the output IV. It is a happy coincidence that the generic CTS
> template encapsulates CBC in a way where its output IV ends up in the
> right place.
>=20
>> Also, these test cases pass on other hardware platforms.
>>=20
>=20
> Fair enough.
>=20
> I am not opposed to fixing this, but given that it is the RFC3962 spec
> that defines that the next IV is the penultimate full block of the
> previous CBC-CTS ciphertext, we might consider doing the memcpy() in
> the Kerberos code not in the CBC-CTS implementations.

Interesting thought. I'm all about proper layering, so I think this
is worth considering. Can you send an RFC patch?

David, any opinion about this for crypto/krb5?


> (The 32-bit ARM
> code will be broken in the same way, and potentially other
> implementations as well)


--
Chuck Lever