Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp7730267ybn; Mon, 30 Sep 2019 19:35:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqwe/uR1P36CUZg8rlhTVSB5dXrv9bnPz7MVSA/1DDkuSXypOh5ThGM7qfKetzwOEt6v4vXL X-Received: by 2002:a17:906:c47:: with SMTP id t7mr22029733ejf.133.1569897301717; Mon, 30 Sep 2019 19:35:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569897301; cv=none; d=google.com; s=arc-20160816; b=qH902KRtxhL7839bvXtEDZHmMc2SOr9nZtK66T9HIJtLEOXqyM42C9E7NGY9Gui1gw QL5zdhYyRI+5MVSwFiad1Iu0F/OI94f6Vq7tcBlCDW1VPOH9qiETST3Qpk+gbjJhMgxH G8E4CQhOGXp3s+S57Ilvdp2d4m8IASPXpQZX6wvFc5zUbvcIZzsmLLKtuFqCTRuG/ovx UNqwMCi7/mRoY0bZagQ9jLfJewHfD0hceSap0Kno/1ghghIn6q7zO/O7Aq3zVmJpjcSy koroTCNX4LfFhsj4iKq1Vth/vIfgaUNXutb9QpzHgnaYbpDyr/WQpFnzhI7OMSoRxycn 7ojw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=u2fMVlEXOztZJna6FXjmFM6uaygOg9sikOopwaobjmU=; b=xQGw7RZDm2T6TbYk4SzpM61HGKsTDZdjDuvbFdPph7kDNbLGDSvw6TljhqKqHA3GJy 3B9e/6uyFw9v07q4ojkx4UUittaxPiISuPd7RS5hT/MzJrhvBPsXMRX+HP2r2h4cHuT2 zueZDEfJ6R+drO08M/Rgfs9pqaMAYb5j/Eh0q0CPDGBuZz8moajS/VpDVK5Wv7HEQq7k rdmAyTO74XkjFpssfjXn/Ms/sEXHto5/cJrCdcHSa4edyUPbCHDGJKDx1FcuphVb/Unn roGMxBYxt9SEbVxGKJsy6QR3HZ71Bts8bCN9xBDyB5iufD5Xs6w/NlDeIcf4kGqsd2fF Nb6w== ARC-Authentication-Results: i=1; mx.google.com; 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 r26si8755352edx.61.2019.09.30.19.34.36; Mon, 30 Sep 2019 19:35:01 -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; 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 S1730797AbfJACbs (ORCPT + 99 others); Mon, 30 Sep 2019 22:31:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:43970 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726789AbfJACbs (ORCPT ); Mon, 30 Sep 2019 22:31:48 -0400 Received: from [213.220.153.21] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iF7wl-0005MK-Uv; Tue, 01 Oct 2019 02:31:28 +0000 Date: Tue, 1 Oct 2019 04:31:27 +0200 From: Christian Brauner To: Kees Cook Cc: Aleksa Sarai , Ingo Molnar , Peter Zijlstra , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Rasmus Villemoes , Al Viro , Linus Torvalds , libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/4] lib: introduce copy_struct_from_user() helper Message-ID: <20191001023126.qhzeiwmtoo4agy7t@wittgenstein> References: <20191001011055.19283-1-cyphar@cyphar.com> <20191001011055.19283-2-cyphar@cyphar.com> <201909301856.01255535BD@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201909301856.01255535BD@keescook> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 30, 2019 at 06:58:39PM -0700, Kees Cook wrote: > On Tue, Oct 01, 2019 at 11:10:52AM +1000, Aleksa Sarai wrote: > > A common pattern for syscall extensions is increasing the size of a > > struct passed from userspace, such that the zero-value of the new fields > > result in the old kernel behaviour (allowing for a mix of userspace and > > kernel vintages to operate on one another in most cases). > > > > While this interface exists for communication in both directions, only > > one interface is straightforward to have reasonable semantics for > > (userspace passing a struct to the kernel). For kernel returns to > > userspace, what the correct semantics are (whether there should be an > > error if userspace is unaware of a new extension) is very > > syscall-dependent and thus probably cannot be unified between syscalls > > (a good example of this problem is [1]). > > > > Previously there was no common lib/ function that implemented > > the necessary extension-checking semantics (and different syscalls > > implemented them slightly differently or incompletely[2]). Future > > patches replace common uses of this pattern to make use of > > copy_struct_from_user(). > > > > Some in-kernel selftests that insure that the handling of alignment and > > various byte patterns are all handled identically to memchr_inv() usage. > > > > [1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and > > robustify sched_read_attr() ABI logic and code") > > > > [2]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do > > similar checks to copy_struct_from_user() while rt_sigprocmask(2) > > always rejects differently-sized struct arguments. > > > > Suggested-by: Rasmus Villemoes > > Signed-off-by: Aleksa Sarai > > --- > > include/linux/bitops.h | 7 +++ > > include/linux/uaccess.h | 70 +++++++++++++++++++++ > > lib/strnlen_user.c | 8 +-- > > lib/test_user_copy.c | 136 ++++++++++++++++++++++++++++++++++++++-- > > lib/usercopy.c | 55 ++++++++++++++++ > > 5 files changed, 263 insertions(+), 13 deletions(-) > > > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > > index cf074bce3eb3..c94a9ff9f082 100644 > > --- a/include/linux/bitops.h > > +++ b/include/linux/bitops.h > > @@ -4,6 +4,13 @@ > > #include > > #include > > > > +/* Set bits in the first 'n' bytes when loaded from memory */ > > +#ifdef __LITTLE_ENDIAN > > +# define aligned_byte_mask(n) ((1UL << 8*(n))-1) > > +#else > > +# define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n))) > > +#endif > > + > > #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE) > > #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_TYPE(long)) > > > > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h > > index 70bbdc38dc37..8abbc713f7fb 100644 > > --- a/include/linux/uaccess.h > > +++ b/include/linux/uaccess.h > > @@ -231,6 +231,76 @@ __copy_from_user_inatomic_nocache(void *to, const void __user *from, > > > > #endif /* ARCH_HAS_NOCACHE_UACCESS */ > > > > +extern int check_zeroed_user(const void __user *from, size_t size); > > + > > +/** > > + * copy_struct_from_user: copy a struct from userspace > > + * @dst: Destination address, in kernel space. This buffer must be @ksize > > + * bytes long. > > + * @ksize: Size of @dst struct. > > + * @src: Source address, in userspace. > > + * @usize: (Alleged) size of @src struct. > > + * > > + * Copies a struct from userspace to kernel space, in a way that guarantees > > + * backwards-compatibility for struct syscall arguments (as long as future > > + * struct extensions are made such that all new fields are *appended* to the > > + * old struct, and zeroed-out new fields have the same meaning as the old > > + * struct). > > + * > > + * @ksize is just sizeof(*dst), and @usize should've been passed by userspace. > > + * The recommended usage is something like the following: > > + * > > + * SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize) > > + * { > > + * int err; > > + * struct foo karg = {}; > > + * > > + * if (usize > PAGE_SIZE) > > + * return -E2BIG; > > + * if (usize < FOO_SIZE_VER0) > > + * return -EINVAL; > > + * > > + * err = copy_struct_from_user(&karg, sizeof(karg), uarg, usize); > > + * if (err) > > + * return err; > > + * > > + * // ... > > + * } > > + * > > + * There are three cases to consider: > > + * * If @usize == @ksize, then it's copied verbatim. > > + * * If @usize < @ksize, then the userspace has passed an old struct to a > > + * newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize) > > + * are to be zero-filled. > > + * * If @usize > @ksize, then the userspace has passed a new struct to an > > + * older kernel. The trailing bytes unknown to the kernel (@usize - @ksize) > > + * are checked to ensure they are zeroed, otherwise -E2BIG is returned. > > + * > > + * Returns (in all cases, some data may have been copied): > > + * * -E2BIG: (@usize > @ksize) and there are non-zero trailing bytes in @src. > > + * * -EFAULT: access to userspace failed. > > + */ > > +static __always_inline > > +int copy_struct_from_user(void *dst, size_t ksize, > > + const void __user *src, size_t usize) > > And of course I forgot to realize both this and check_zeroed_user() > should also have the __must_check attribute. Sorry for forgetting that > earlier! Just said to Aleksa that I'll just fix this up when I apply so he doesn't have to resend. You ok with this, Kees? > > With that, please consider it: > > Reviewed-by: Kees Cook Reviewed-by: Christian Brauner