From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F540C43381 for ; Tue, 26 Feb 2019 12:38:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 33511217F9 for ; Tue, 26 Feb 2019 12:38:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=nxp.com header.i=@nxp.com header.b="Xmuhjxl3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726816AbfBZMiM (ORCPT ); Tue, 26 Feb 2019 07:38:12 -0500 Received: from mail-eopbgr30064.outbound.protection.outlook.com ([40.107.3.64]:20271 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726063AbfBZMiM (ORCPT ); Tue, 26 Feb 2019 07:38:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HzKfLVHVA/7/S3a4pjWgY2nK6Nl/Hs8WqyZrYlK2zyo=; b=Xmuhjxl3V7XVmsdvqzIuD4Cu+C6P5WCWhSOI56c69xKz9Um/oGBJkHUas1m+rJRpWkohn10++C1P/w1hmpdfe/ZpjjYals3hHeTYbyVQVRv0BOK47zull8oyN1XL9q0AYM7xPs/l4RXLwKtjolQITiTM79NDBCbJOW/knTg/MPM= Received: from DB7PR04MB4252.eurprd04.prod.outlook.com (52.135.131.26) by DB7PR04MB4747.eurprd04.prod.outlook.com (20.176.233.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.20; Tue, 26 Feb 2019 12:38:07 +0000 Received: from DB7PR04MB4252.eurprd04.prod.outlook.com ([fe80::9ca:d78:c154:25b5]) by DB7PR04MB4252.eurprd04.prod.outlook.com ([fe80::9ca:d78:c154:25b5%4]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 12:38:07 +0000 From: Vakul Garg To: Boris Pismenny , "aviadye@mellanox.com" , "davejwatson@fb.com" , "john.fastabend@gmail.com" , "daniel@iogearbox.net" , "netdev@vger.kernel.org" CC: "eranbe@mellanox.com" Subject: RE: [PATCH net 3/4] tls: Fix mixing between async capable and async Thread-Topic: [PATCH net 3/4] tls: Fix mixing between async capable and async Thread-Index: AQHUzcydcVGt4AhRU0u3fPEt0OX60KXyAozw Date: Tue, 26 Feb 2019 12:38:07 +0000 Message-ID: References: <20190226121235.20784-1-borisp@mellanox.com> <20190226121235.20784-4-borisp@mellanox.com> In-Reply-To: <20190226121235.20784-4-borisp@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=vakul.garg@nxp.com; x-originating-ip: [160.202.37.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9194c1e7-5ebd-41e5-bc03-08d69be74287 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020);SRVR:DB7PR04MB4747; x-ms-traffictypediagnostic: DB7PR04MB4747: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1;DB7PR04MB4747;23:6mTb4wyPVBIKNOhMJ/a9QiOu2SCAreJ2R0L0z+UaO?= =?us-ascii?Q?I4bFBNdM9Keu96HOxDwpYxcx/7IiSQODki1256KDW9d+u0WryBsJW12if6FD?= =?us-ascii?Q?HrDwvpCFmcRRvccyTIpTUD0Eu7aICdtqVXOwmWnJI3rSdNlLyt9mXuEjQjvH?= =?us-ascii?Q?Tw6dIWm4vFapt3a6gyJasGOqyPKa80567EGnvKDoWjVRwc1Wkpyzw7Lv6CIZ?= =?us-ascii?Q?fAHMlkdavSYEN7r0mRju412FgtIXcXcgQdhbKgCj5jmNoxJB02Qn99eQTz/w?= =?us-ascii?Q?WaFDb0f/2JVIJEV7Y5PpXssQHECTQ9gk/j2Sr6wnEWVDoQ1U/Q/48IlLX4oA?= =?us-ascii?Q?kaEqIduyOjX+7cqT6lG5WuSPaj2nUzV527FajYtBqGku9Z1sGWC8XUYuYECa?= =?us-ascii?Q?rVmGENps/ynczoFR1q8Y1yFV7UTUa8Xv5kRSdY+3zE5kPbm/2NkB6fxItt0D?= =?us-ascii?Q?ZStkgSQyJSf36PP9uMILdTUf/h/VZkY1EwRdBb53+973c3c7xDZibko1UEuQ?= =?us-ascii?Q?AXx8hH740D7A82Hs9ca/O/FOPkwV6VYpSnl/5KbrKVA/aeArS4KhP2iZP6Ra?= =?us-ascii?Q?yi+Xnm4JxfnzuSQ2LVQi8ymSCAsKstngYGS+56fHSBKrUeGeVO6a7gAKIqQ5?= =?us-ascii?Q?hhyapAA2Xujdq7u1KUHFYOpddNQ/AFToowWmfiFpl8YsGTP+ke41yZ/rgdTh?= =?us-ascii?Q?xRSkpmDj5FQsnsohCQdkWB9JJKf5eUHBfkOFlhU9KwNJ88Dg+oaKvvc1vPD9?= =?us-ascii?Q?5us+tC/b0wf++0YTygOX+ZzSXg8t7D1677+/ydKXFlbGXtpR7WaA3u77Tkib?= =?us-ascii?Q?2Xeu4uyAFEexnw3cn4N/56ruIpdWuyvsK+mP2O3mbkEoV8MXAEn6/Tehs6NM?= =?us-ascii?Q?m+6zgjwKZL73IUsRJBlLxTX08SmJ/esXCcr6fiBpaPtmSmTKeQ3T5u3H26Hf?= =?us-ascii?Q?IzMzWB1IsiOOlG/0bqf3M2wIyfQlBgrQH0eAw/ImhPjOBRQeOOtGDgDfamOh?= =?us-ascii?Q?JS7m0b8Zv/JaCyhruwuU5n/vfd19AZR8t6pli+pCT7N4G/B99x5bSLThVXfS?= =?us-ascii?Q?HH+G4Q9dYIiX1KDQSEqicTc4fN4wn3ulQgbWeQgeXv3+KD5AuBQWj7yuOdi1?= =?us-ascii?Q?hiZuByLJGZIHKiTWy6jHZddHd3VFZ4GvepE8iNzqzzVlYciiXsg73Upl8B5g?= =?us-ascii?Q?1fc7pXoQaSlKqydEgMLhup1F1kO/XVzWKM1wLSeQcU0qWnGEgalk5r0EPsqp?= =?us-ascii?Q?EJhc9mlN3MjjtBm7YHNa+fsGBCO1hnATjHUlde9I8gET0OI+7uXFT4KvFcGE?= =?us-ascii?Q?c0X3Qa+mNr0bbQWKaH2FaU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(39860400002)(366004)(346002)(136003)(376002)(396003)(13464003)(189003)(199004)(74316002)(110136005)(86362001)(2201001)(68736007)(2906002)(186003)(71200400001)(55016002)(6246003)(71190400001)(7696005)(6116002)(3846002)(76176011)(25786009)(7736002)(5660300002)(305945005)(2501003)(8676002)(81156014)(8936002)(81166006)(316002)(14444005)(256004)(4326008)(106356001)(14454004)(229853002)(52536013)(44832011)(97736004)(478600001)(53936002)(6436002)(486006)(26005)(476003)(11346002)(66066001)(33656002)(105586002)(99286004)(9686003)(6506007)(102836004)(53546011)(446003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB7PR04MB4747;H:DB7PR04MB4252.eurprd04.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jOiqR5p9/gTLxmc5XzKJQrABwHaMANy4/hIPaeWfMOxz5FRbiShCUSxIP+ttb+LoiYDvTvb/lBIQw3XBX/7StgTd87so+Mz/Y0/g76Yl17nhBGzIuoGOS6EQGbks6MUnOu5QfffmXvWHEaV41cbJigyvRs6zBoSuQj/4SdMmBsc9jhOkcnb7UMlGiHJLzG1K8KvMUMZmPiO8qGW21Xkyx34om0gW2talgwhsFX218cF2qNptu5zJzHEGgAFR/P7ts+oRtfdZd64n+9WOhDrxtvkIkofOKNUTJD5npUtAIMRCsxilMaCgtInZvjDSkuOTnwcMG+VgOFTs9gDgU7gTlzwznvtGgkkGHu5s6zhL1K2PSofjvVyIpv1ElW/y3W6IrPAZTJXy5TJ0XnZ2rX/vvcIccv2fQBvbsEedlViPgEg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9194c1e7-5ebd-41e5-bc03-08d69be74287 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 12:38:07.4275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB4747 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: Boris Pismenny > Sent: Tuesday, February 26, 2019 5:43 PM > To: aviadye@mellanox.com; davejwatson@fb.com; > john.fastabend@gmail.com; daniel@iogearbox.net; Vakul Garg > ; netdev@vger.kernel.org > Cc: eranbe@mellanox.com; borisp@mellanox.com > Subject: [PATCH net 3/4] tls: Fix mixing between async capable and async >=20 > From: Eran Ben Elisha >=20 > Today, tls_sw_recvmsg is capable of using asynchronous mode to handle > application data TLS records. Moreover, it assumes that if the cipher can= be > handled asynchronously, then all packets will be processed asynchronously= . >=20 > However, this assumption is not always true.=20 Could you please elaborate, what happens? > Specifically, for AES-GCM in > TLS1.2, it causes data corruption, and breaks user applications. >=20 > This patch fixes this problem by separating the async capability from the > decryption operation result. >=20 > Fixes: c0ab4732d4c6 ("net/tls: Do not use async crypto for non-data > records") > Signed-off-by: Eran Ben Elisha > Reviewed-by: Boris Pismenny > --- > net/tls/tls_sw.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) >=20 > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index > 4afa67b00aaf..f515cd7e984e 100644 > --- a/net/tls/tls_sw.c > +++ b/net/tls/tls_sw.c > @@ -1693,7 +1693,8 @@ int tls_sw_recvmsg(struct sock *sk, > bool zc =3D false; > int to_decrypt; > int chunk =3D 0; > - bool async; > + bool async_capable; > + bool async =3D false; >=20 > skb =3D tls_wait_data(sk, psock, flags, timeo, &err); > if (!skb) { > @@ -1727,21 +1728,23 @@ int tls_sw_recvmsg(struct sock *sk, >=20 > /* Do not use async mode if record is non-data */ > if (ctx->control =3D=3D TLS_RECORD_TYPE_DATA) > - async =3D ctx->async_capable; > + async_capable =3D ctx->async_capable; > else > - async =3D false; > + async_capable =3D false; >=20 > err =3D decrypt_skb_update(sk, skb, &msg->msg_iter, > - &chunk, &zc, async); > + &chunk, &zc, async_capable); > if (err < 0 && err !=3D -EINPROGRESS) { > tls_err_abort(sk, EBADMSG); > goto recv_end; > } >=20 > - if (err =3D=3D -EINPROGRESS) > + if (err =3D=3D -EINPROGRESS && async_capable) { Why do we need to check 'async_capable'?=20 Do we get err =3D=3D -EINPROGRESS even when async_capable is false? > + async =3D true; > num_async++; > - else if (prot->version =3D=3D TLS_1_3_VERSION) > + } else if (prot->version =3D=3D TLS_1_3_VERSION) { > tlm->control =3D ctx->control; > + } >=20 > /* If the type of records being processed is not known yet, > * set it to record type just dequeued. If it is already known, > -- > 2.12.2 =20