Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp238198imm; Thu, 6 Sep 2018 01:26:58 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZYhtuNMDr9eiHNr0tnqkbyHXMMYZF7kO47B6y7OlO701Wpyxyv7W+iY6ct/sPx/FQZw0hQ X-Received: by 2002:a17:902:280a:: with SMTP id e10-v6mr1558165plb.187.1536222418441; Thu, 06 Sep 2018 01:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536222418; cv=none; d=google.com; s=arc-20160816; b=BQIx+iPrx+aEN2DDTk7x/8cYnet2ZcFXks3o00BhKRUjJzJSaO6pzBM6NiXHOmPMBI Lr4VV/MgY6/VGMzUlWzILbt+WZ5RMTeyT7NopaJF+gpyXPz8MLU3Q1G3nXbsEexzuex5 ycPn/fnAEgvbPvKqiKchrzuHr/lSOBAJguECsEjc0RyxExDnbCQXENLR3bSHtD1bHbqU om2A0nLOTRgKupyCPqyyQgp47ZtiAqD0FtmfJ4S0O0IAQ+JWjS0xnHBe4K1fj6Y0ULll P4v3JlF8htUxjIYYw5QwoNrEM4XFVFiEP1c/eStDCoz3+Tv3B1+GK7PSY/yGuLRZwv9i WYcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature; bh=niyIivPhj74NaJa0LzdrrN6R/cSC6E2p/MWYnyTchpQ=; b=wiXidXDMi38xWtFGQxJsDVEbfFLkc9hyHEFi/jyEsxQL99uK+lEntg4ozMhFyITU6E WrBqPbPtQJMWx7ZtMsTxK/O8/Zl2ZSeoT/OCAbYkSpEGEmbnlO4Kwggf8EMUbzKaD/IO EdG19PoA7J1L8NLApcCMhJSdGuqJFT3kQ8JwUTmdqDKFJVLJrZIrCBeMQd9dtXVxHr4o RxCHypZpWj5fpI1QwSRgz9m0op3MWPiZto8bFcHtTjbIsQ+pE3Ux5WZclrwEmRTlkY5m AbG9O0z3y1b+NR1wuP86Ezifm+aZO+dUHucWrnfl125EmoVWjXrKDzj10HO7PLgfWqlt JAPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=ppA9uqsT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 g70-v6si4491729pfd.86.2018.09.06.01.26.43; Thu, 06 Sep 2018 01:26:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=ppA9uqsT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728018AbeIFM7V (ORCPT + 99 others); Thu, 6 Sep 2018 08:59:21 -0400 Received: from mail-ua1-f67.google.com ([209.85.222.67]:44333 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725809AbeIFM7V (ORCPT ); Thu, 6 Sep 2018 08:59:21 -0400 Received: by mail-ua1-f67.google.com with SMTP id m11-v6so8029798uao.11 for ; Thu, 06 Sep 2018 01:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benyossef-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=niyIivPhj74NaJa0LzdrrN6R/cSC6E2p/MWYnyTchpQ=; b=ppA9uqsTQNq1eDBFJ+kp1rV8802kdKafWpvJaiYYz+/gX7dVpVBGu+Tky+A5E7eUXX UZiYeMdK5yyc5Jiv0pbou+LjdMAjqAbo6P5Un0PP17Lmob+beHne+wSberlj3KWZOXCZ oPNfrj+cjeKuX+HCRvJ/cAOBFNKlN8xEWZRElKsoO/5yvwAhPmjVccerlGsRj995AdFk 3b56VOl480BNPtPwEuzeCcV9FeS8duGFl0ekMVIKMJwHdWMNrJGsv0D+JVMT0tzS8B7S KfDXBGcO45bmaTuPtiZYi8WDEY6lejhU6OEtkGk99N1O0gjQBpJcZoRnqY2vFQUiA1By Jv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=niyIivPhj74NaJa0LzdrrN6R/cSC6E2p/MWYnyTchpQ=; b=NV8yhLqGuhk0uGGst5WXNSTCbk//+cjsXcr42kAi3bM0EVphDgx1+L/ZFytab6LQPS Zsqyihak5XSoA069mQUrSb7R8jPqxZiM5L4B1STyNxc2W1/xG3tnDooMss3gfY7JLbqb iMlrGRh3dxC5IwKqdaRbSZ3ihMvjLbTLZEioIXSVB/vk+9G+gyOPRgmviX6uuk5qZBWH fYXEWyRuNLeFPq3Dnzl+ckDnU0Xwba95Uv9iNt1GnzqWaPqiarg/TH0aRC6ISQoQLLmW 9YkzLdpEqQQ78AqcpUveUkIhLXhZDWafUdK4swXGFrmK/gpYxTQThTnAPUWcaaDJa2Ad JkKQ== X-Gm-Message-State: APzg51DGjiD7NaVaG2V2zWqYjs7ovqON3UU9AMKuTWPaHWE6SDdU0/Tu tcrFpsIGUO0WlJfTN8z1V0giaKGXSrL7EqkR3qp6adlphAdgBg== X-Received: by 2002:ab0:42a6:: with SMTP id j35-v6mr564555uaj.143.1536222302444; Thu, 06 Sep 2018 01:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:464:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 01:25:02 -0700 (PDT) X-Originating-IP: [217.140.106.29] In-Reply-To: References: <20180904181629.20712-1-keescook@chromium.org> <20180904181629.20712-3-keescook@chromium.org> From: Gilad Ben-Yossef Date: Thu, 6 Sep 2018 11:25:02 +0300 Message-ID: Subject: Re: [PATCH 2/2] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK To: Ard Biesheuvel Cc: Kees Cook , Herbert Xu , Eric Biggers , Antoine Tenart , Boris Brezillon , Arnaud Ebalard , Corentin Labbe , Maxime Ripard , Chen-Yu Tsai , Christian Lamparter , Philippe Ombredanne , Jonathan Cameron , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Linux Kernel Mailing List , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 6, 2018 at 10:21 AM, Ard Biesheuvel wrote: >>> The skcipher implementations based on crypto IP blocks are typically >>> asynchronous, and I wouldn't be surprised if a fair number of >>> SKCIPHER_REQUEST_ON_STACK() users are limited to synchronous >>> skciphers. >> >> According to Herbert, SKCIPHER_REQUEST_ON_STACK() may only be used >> for invoking synchronous ciphers. >> >> In fact, due to the way the crypto API is built, if you try using it >> with any transformation that uses DMA >> you would most probably end up trying to DMA to/from the stack which >> as we all know is not a great idea. >> > > Ah yes, I found [0] which contains that quote. > > So that means that Kees can disregard the occurrences that are async > only, but it still implies that we cannot limit the reqsize like he > proposes unless we take the sync/async nature into account. > It also means we should probably BUG() or WARN() in > SKCIPHER_REQUEST_ON_STACK() when used with an async algo. > >>> >>> So we could formalize this and limit SKCIPHER_REQUEST_ON_STACK() to >>> synchronous skciphers, which implies that the reqsize limit only has >>> to apply synchronous skciphers as well. But before we can do this, we >>> have to identify the remaining occurrences that allow asynchronous >>> skciphers to be used, and replace them with heap allocations. >> >> Any such occurrences are almost for sure broken already due to the DMA >> issue I've mentioned. >> > > I am not convinced of this. The skcipher request struct does not > contain any payload buffers, and whether the algo specific ctx struct > is used for DMA is completely up to the driver. So I am quite sure > there are plenty of async algos that work fine with > SKCIPHER_REQUEST_ON_STACK() and vmapped stacks. You are right that it is up to the driver but the cost is an extra memory allocation and release *per request* for any per request data that needs to be DMAable beyond the actual plain and cipher text buffers such as the IV, so driver writers have an incentive against doing that :-) Gilad --=20 Gilad Ben-Yossef Chief Coffee Drinker values of =CE=B2 will give rise to dom!