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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 03D3AC3A5A5 for ; Thu, 5 Sep 2019 11:17:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C92F322CF5 for ; Thu, 5 Sep 2019 11:17:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=rasmusvillemoes.dk header.i=@rasmusvillemoes.dk header.b="TmAHYZxq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388295AbfIELRn (ORCPT ); Thu, 5 Sep 2019 07:17:43 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:38623 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388291AbfIELRn (ORCPT ); Thu, 5 Sep 2019 07:17:43 -0400 Received: by mail-lj1-f193.google.com with SMTP id y23so1709959ljn.5 for ; Thu, 05 Sep 2019 04:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FZQLTiI56V9ejCTERxmKEuoyOsqpXI4ROWUat/u48IQ=; b=TmAHYZxqRc6xu2le8iULfxikI7ku0uT9OqruTeiVIjBtHlSUVtr7xfmu4YCFlsjTOs Rhq1GYmaO5KwXBXGMlzcAxQ/LcO6e9A60OIH5XcxDVVNn2uwqfJXj5l04xQJTBjas8S+ rezhJDHHi4QSeAmUuvBdnaXdMHr6k1YEDw8fQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FZQLTiI56V9ejCTERxmKEuoyOsqpXI4ROWUat/u48IQ=; b=KIBbmvgBvXGxsBf9U73XUq6ybbrQGybYOfVH+yGGDhY3bW9Ty+5zDV5J7XxrZdQuJ+ F/dQJ6xdSbZgAYwZtGK8y0iT6MDdskCRLkxKG66u7EYwt45VXlHwAlN2V0X9cig16RT/ yuykZG57iix+yu4nCDyV+7k82dMpc655e9hoqQvFn0vckTYQzbasNzYw4rDZ/6KnCaMH fA3KhZ78FI1V1WR8+Wr2DNcJko+1/7puZvL4T6c/7joxnNwroSlA3AaPSZFnQWeX5CWu KNs1Oa/8WK2XmLRb432Kd3bHdnwE+9TxowclcMGKPpBfy6lB82KBEzMXnfcKXU1bTxBA qnoA== X-Gm-Message-State: APjAAAUeAIyklYxq7eZFRQb/NiVjXGGTZuTV8iPjisnOiPiUYAe1knaJ YmgYPE3dG1ZEwqkjm+VoOiaTOQ== X-Google-Smtp-Source: APXvYqy+jIyWA4s/Awrv2CCVQWWEoIb0eYt4SAhqVoZ9KSv6Iim6pns0uTxVPV5vb5IsmAlCA9M4vg== X-Received: by 2002:a2e:5418:: with SMTP id i24mr1705390ljb.126.1567682261376; Thu, 05 Sep 2019 04:17:41 -0700 (PDT) Received: from [172.16.11.28] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id l3sm377157lfc.31.2019.09.05.04.17.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 04:17:40 -0700 (PDT) Subject: Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers To: Christian Brauner , Aleksa Sarai Cc: Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Shuah Khan , Shuah Khan , Ingo Molnar , Peter Zijlstra , Christian Brauner , Eric Biederman , Andy Lutomirski , Andrew Morton , Alexei Starovoitov , Kees Cook , Jann Horn , Tycho Andersen , David Drysdale , Chanho Min , Oleg Nesterov , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Aleksa Sarai , Linus Torvalds , containers@lists.linux-foundation.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-2-cyphar@cyphar.com> <20190905110544.d6c5t7rx25kvywmi@wittgenstein> From: Rasmus Villemoes Message-ID: Date: Thu, 5 Sep 2019 13:17:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190905110544.d6c5t7rx25kvywmi@wittgenstein> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On 05/09/2019 13.05, Christian Brauner wrote: > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote: >> + if (unlikely(!access_ok(dst, usize))) >> + return -EFAULT; >> + >> + /* Deal with trailing bytes. */ >> + if (usize < ksize) { >> + if (memchr_inv(src + size, 0, rest)) >> + return -EFBIG; >> + } else if (usize > ksize) { >> + if (__memzero_user(dst + size, rest)) >> + return -EFAULT; > > Is zeroing that memory really our job? Seems to me we should just check > it is zeroed. Of course it is, otherwise you'd require userspace to clear the output buffer it gives us, which in the majority of cases is wasted work. It's much easier to reason about if we just say "the kernel populates [uaddr, uaddr + usize)". It's completely symmetric to copy_struct_from_user doing a memset() of the tail of the kernel buffer in case of ksize>usize - you wouldn't want to require the kernel callers to pass a zeroed buffer to copy_struct_from_user() - it's just that when we memset(__user*), there's an error check to do. Rasmus