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 3407DC3A5A5 for ; Thu, 5 Sep 2019 11:17:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C9A922CF5 for ; Thu, 5 Sep 2019 11:17:47 +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 S2388300AbfIELRn (ORCPT ); Thu, 5 Sep 2019 07:17:43 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39906 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388286AbfIELRn (ORCPT ); Thu, 5 Sep 2019 07:17:43 -0400 Received: by mail-lj1-f194.google.com with SMTP id j16so2039874ljg.6 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=nSht4xPezi42cVMPMyJpjKT7Ul12gZ8d60WryYnBLgAVQczAryLFQXNuuwT11HhmAk K4x35oRzAQUoryivfJ92kl6zNRJkx96t0IBWZL/kHUTpYNFtH7qimucwJ2lsaak8roEd Vrp9t2FN+lY014YmX2VcAp+TyAOOKGytcLfZs7xF68bTXBvhyTF7gNtfF0lj2bCkLltl OWYgFO8czr3kPNnkprO2+kK5E/4XJhk7h7hlJh97BORKYnu2hShwy5TaoRLK7DfvO3/R WhiGThVrv/pIC/d69Nn6T69PSbHWKK3tH+RbzbZwyJSkCiLu+XZt8eHaHGy0pbI7LzYR u2hg== X-Gm-Message-State: APjAAAX9ZM0PvbQ7Z/n6xngvc9/Q1yvIvtGpio0v2T1HJpdlcHQ/1D8t LcvYthxq9LZ0oJyBCKVZ9iN9mA== 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-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@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