Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp7665810ybn; Mon, 30 Sep 2019 18:12:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqy2UFASG4/Uu+7OA65ans4uU6bt/LE4sb3wAQZsolVFcnfHyzFHfrnjZ20Cwnnoz1VfOZxm X-Received: by 2002:a50:baa5:: with SMTP id x34mr23597091ede.148.1569892331336; Mon, 30 Sep 2019 18:12:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569892331; cv=none; d=google.com; s=arc-20160816; b=klmT7o0r1hGxi7X6Pzii04Debal6OU74nmTHL5xwf7B7mcQ90S8YW154DpK57Uqvot gE3JoND0OAkzrpN43jiW346FWLVCkJXPZn+Pw7V9SxGvTALRXUMnXEPOVRph8ZsOrTTZ mRLe7ahDlkazZxdhjsYKIs83lih8a8FgsW2iak7gPElrAtkiJJUdKX6oNcgIgpPxXgpV fC0kFHaUJsnkNtAbPgI0JYm3/QKjKPZtCO0fK4VgCn+fU6RlbsQXUCUtYnNl7hStLmhl 1B9MDOm6kiPvhQnGYeWv+0NAlFnATNmu1puWA19esofGAcAkp0l5ckqaSSd2KnrsdoFQ /txQ== 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:mime-version :message-id:date:subject:cc:to:from; bh=tWYggUNdOHA9R2mgPRZhhESFXoknPI1HYIuTtMn/qKg=; b=GmFycuNMt4QtMvGGd6u6HrkBSWsRo97GVZqEAZwQxaH/3Yd4qCc13tPgUpD3FZZgwN THruKwogTxgizKXmeWqyG65slZtV/q5DkHyDazBH8YqY6SIE7D//EETUKzX9nqfcqbq2 aeD6i853VY+SJSQqaCFpWjsHsUJc+Hb6o3jUtts/ylQgU+fyE9SjuPTY8I3ClkZtdh4j q0ABhR1S4hhnpSo5Sq6emPUbuDEsw1fRNteaV2uzwCsQLEJULhcWlKUW0kQFJivXcIM7 NgUOE5fbK5USGJCvhooNwSYiJFFoeQil3gLMedNwFda2iIPxl36UMMuzMr7vKSjSQUXB KMtQ== 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 n4si7335790ejj.132.2019.09.30.18.11.45; Mon, 30 Sep 2019 18:12:11 -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 S1729504AbfJABLl (ORCPT + 99 others); Mon, 30 Sep 2019 21:11:41 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:36932 "EHLO mx2.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726314AbfJABLk (ORCPT ); Mon, 30 Sep 2019 21:11:40 -0400 Received: from smtp2.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 24BC8A2212; Tue, 1 Oct 2019 03:11:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id J7q4_S4uKmke; Tue, 1 Oct 2019 03:11:33 +0200 (CEST) From: Aleksa Sarai To: Ingo Molnar , Peter Zijlstra , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Christian Brauner , Kees Cook Cc: Aleksa Sarai , Rasmus Villemoes , Al Viro , Linus Torvalds , libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 0/4] lib: introduce copy_struct_from_user() helper Date: Tue, 1 Oct 2019 11:10:51 +1000 Message-Id: <20191001011055.19283-1-cyphar@cyphar.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Patch changelog: v4: * __always_inline copy_struct_from_user(). [Kees Cook] * Rework test_user_copy.ko changes. [Kees Cook] v3: v2: v1: This series was split off from the openat2(2) syscall discussion[1]. However, the copy_struct_to_user() helper has been dropped, because after some discussion it appears that there is no really obvious semantics for how copy_struct_to_user() should work on mixed-vintages (for instance, whether [2] is the correct semantics for all syscalls). 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). Previously there was no common lib/ function that implemented the necessary extension-checking semantics (and different syscalls implemented them slightly differently or incompletely[3]). This series implements the helper and ports several syscalls to use it. Some in-kernel selftests are included in this patch. More complete self-tests for copy_struct_from_user() are included in the openat2() patchset. [1]: https://lore.kernel.org/lkml/20190904201933.10736-1-cyphar@cyphar.com/ [2]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code") [3]: 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. Aleksa Sarai (4): lib: introduce copy_struct_from_user() helper clone3: switch to copy_struct_from_user() sched_setattr: switch to copy_struct_from_user() perf_event_open: switch to copy_struct_from_user() include/linux/bitops.h | 7 ++ include/linux/uaccess.h | 70 +++++++++++++++++++ include/uapi/linux/sched.h | 2 + kernel/events/core.c | 47 +++---------- kernel/fork.c | 34 ++-------- kernel/sched/core.c | 43 ++---------- lib/strnlen_user.c | 8 +-- lib/test_user_copy.c | 136 +++++++++++++++++++++++++++++++++++-- lib/usercopy.c | 55 +++++++++++++++ 9 files changed, 288 insertions(+), 114 deletions(-) -- 2.23.0