Received: by 10.213.65.68 with SMTP id h4csp2831679imn; Mon, 9 Apr 2018 09:42:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/l5aWwego0o65iifXg9e8gahXHEcQ2vwAi14qA+F0xty2vgby4O/1uqNSXPPoXx9aQVLLN X-Received: by 10.98.178.29 with SMTP id x29mr30222495pfe.44.1523292147202; Mon, 09 Apr 2018 09:42:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523292147; cv=none; d=google.com; s=arc-20160816; b=zCmKxNM5YOstIKpuDPo0VWq02weom2NpAJp4JI2aGq2WbqeLONKkpnfe1IrjE6dJwE T9S5xwOwOP7UpMPMHLomMoCRH5ytguudb+gpnt0M0OOGrfpy/gpME17AmOZSAHeUpPQ3 oJZ2KoJ195bOAI+u9mkGil185E11de3sl6HjBkLNMfWgd+iL2kRtqS2venHx2g+4pj5D VLP/wOX/0+/9XJvuA81rdNs3Rwy2hCIcUtvwNWs07r6UTA/ONJLZJ5zbCb2ZZGub1mv5 3CnJYBrj2qJNx2n3LZmCARFLmLj2j4FIXQBRnfm12SSLEeUvI5LsY7oUyTKJkZY5sl62 PJ9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=yRF0VqoYqq+19Qwac1dv26g7pfejHFUg8WaWS0GFFVg=; b=tX2Z18iTLOmA1O5oMxyhYiWg4FnvlrSVmiEpS5EPRTpi0eIlcqpHwGkreusvoS4SyB 3WdZoYb+hj+4yS+VWn8/6ejYn6BggK0/q07XGGNG43XNH9tQR2cU+PB1yuiC0kH7zT5W IvOYMYuVTlckG1LdoY8QZUoDI48IXeLJzjdJnVdbxFWRL7NJf1y8UNn+UfMPl137t9P0 ymS2C0jVKwWjTQ/7DTP9z7zj582hivCIaOzwL643bPUIchAJA/O3V/jFk+PJItEHnPR0 Gec4T8txtUL4x8JgsGOmrWJxFud8HZdkBJ6CCywP0L03BihBVNu8jOCPs21MCge9X5ys YUOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bvGjskTU; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2-v6si630229plh.44.2018.04.09.09.41.49; Mon, 09 Apr 2018 09:42:27 -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=@gmail.com header.s=20161025 header.b=bvGjskTU; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753099AbeDIQim (ORCPT + 99 others); Mon, 9 Apr 2018 12:38:42 -0400 Received: from mail-ua0-f182.google.com ([209.85.217.182]:35020 "EHLO mail-ua0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751662AbeDIQik (ORCPT ); Mon, 9 Apr 2018 12:38:40 -0400 Received: by mail-ua0-f182.google.com with SMTP id c3so5404258uae.2; Mon, 09 Apr 2018 09:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yRF0VqoYqq+19Qwac1dv26g7pfejHFUg8WaWS0GFFVg=; b=bvGjskTUrPik+SVEk2KNbAye0JwEWD3sX8gUWzqs3Da4pikBTaWnTMTh1W2hLgoqdc c+D4U/fOu+mb3JeIyTJljlsbiMp8wCdFbQRwsbsAV01NT8dbwae3QgnTxKo+AoE95wy9 MzL4ki7iGIcagRuOQgoqL4EZ8YO6tJv2flVk48SweEqSHRUbjWU3kJcUYjPp1MoDExcS 1IUNDJHB4JFfQSvfMH7NpJ4Nfuu9VrPijjXkr8h0LeHgly8uPMeqN9oV1qTIbEaNLAoI ZBo3jTzUCbKkRHcseycY+rrwYWGzKKXT45bRci1pNCXdYFv87GZeu+vfmra+WtiuWLs2 azqg== 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; bh=yRF0VqoYqq+19Qwac1dv26g7pfejHFUg8WaWS0GFFVg=; b=m7ha5F96j6RvmCSZQls0I2Ui0q2Np5kV8oVwl4jQUSdYb7UTYfLiQBDahovmxa4y2S hl8JvVtgbL7sUMWDKcPMoQvUJIerPnnFe1Lk9yGvuM1w2yiICnwVTfwQ/Y1hFO6+yytt UKEgyHGg6tyYBKBAajQYUpPP2wva+G0VkqFWPKrgQTYnG5QJ5biQerkQlQdaCrFvjGVx Cnxkg35nlAR0sSxPnFi4g7Kcj/jRyXr52cEM4dHvD2TP5VCE3Fb4inqVW3EUi8sapn/N nwT0MdI+GgVW4WPCmg149vQVpYlVTcU9Yn7C9rgXtq4/fR3QpzoOGc0v3M+yMTxrZV9m IuAQ== X-Gm-Message-State: ALQs6tCAeuHeBvIyHV6dRGH2KbrSgOTifBzDR9YzhBI3oNsiUk2cuh1a me7i+7YrqttNuRrbOyjo18wI6r5+shrpVMVKkxw= X-Received: by 10.176.36.196 with SMTP id k4mr24639276uan.6.1523291919524; Mon, 09 Apr 2018 09:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.179.9 with HTTP; Mon, 9 Apr 2018 09:38:18 -0700 (PDT) In-Reply-To: References: <1523282087-22128-1-git-send-email-s.mesoraca16@gmail.com> From: Salvatore Mesoraca Date: Mon, 9 Apr 2018 18:38:18 +0200 Message-ID: Subject: Re: [PATCH v2 0/2] crypto: removing various VLAs To: David Laight Cc: "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , "linux-crypto@vger.kernel.org" , "David S. Miller" , Herbert Xu , Kees Cook , Eric Biggers , Laura Abbott Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-04-09 16:35 GMT+02:00 David Laight : > From: Salvatore Mesoraca >> Sent: 09 April 2018 14:55 >> >> v2: >> As suggested by Herbert Xu, the blocksize and alignmask checks >> have been moved to crypto_check_alg. >> So, now, all the other separate checks are not necessary. >> Also, the defines have been moved to include/crypto/algapi.h. >> >> v1: >> As suggested by Laura Abbott[1], I'm resending my patch with >> MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they >> can be used in other places. >> I took this opportunity to deal with some other VLAs not >> handled in the old patch. > > If the constants are visible they need better names. > Maybe CRYPTO_MAX_xxx. You are right, in fact I renamed them, but forget to write about this in the change log. The new names look like MAX_CIPHER_*. > You can also do much better than allocating MAX_BLOCKSIZE + MAX_ALIGNMASK > bytes by requesting 'long' aligned on-stack memory. > The easiest way is to define a union like: > > union crypto_tmp { > u8 buf[CRYPTO_MAX_TMP_BUF]; > long buf_align; > }; > > Then in each function: > > union tmp crypto_tmp; > u8 *keystream = PTR_ALIGN(tmp.buf, alignmask + 1); > > I think CRYPTO_MAX_TMP_BUF needs to be MAX_BLOCKSIZE + MAX_ALIGNMASK - sizeof (long). Yeah, that would be nice, it might save us 4-8 bytes on the stack. But I was thinking, wouldn't it be even better to do something like: u8 buf[CRYPTO_MAX_TMP_BUF] __aligned(__alignof__(long)); u8 *keystream = PTR_ALIGN(buf, alignmask + 1); In this case __aligned should work, if I'm not missing some other subtle GCC caveat. Thank you, Salvatore