Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp493871imm; Mon, 2 Jul 2018 15:46:09 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeOgrwSX4X90PyMaNGVEor5VBphcWj9tFwlQrUFOTt5PmmJ+cISU93VwTUw53HcL6zqPOLP X-Received: by 2002:a62:4a51:: with SMTP id x78-v6mr27262148pfa.45.1530571569147; Mon, 02 Jul 2018 15:46:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530571569; cv=none; d=google.com; s=arc-20160816; b=ay7oEqkuHMBexpXrHIK6PrrliyWBg12rUAztn7ZOn5BQq1JEv5UkGitGnmUSb/2CIH FMwhAckUy/8i3QVPqquAmQ0AzFak3HXJkUG4uAyUTcFts4SloapNMr2wW+4fqLrD6O+C lCknh9Ogq2wsovPXxLeqWGnGvOPI/V0cy9nTR/vM6KOeVc1woUvbcOMeRziO6sUJtgHA CKoezzwhBH6QmIsfIER9QwB7ENwRHQUTJjbqAtjIBFloJCKO2BufVlHTGyPRiZKqX61m w/fTS4BSFc+lK2HUTZi/DBjaniElteMLEp9cD40X7LPk6DwEDJkgukBCIei2ubAOcb5T R+4w== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=caasTxZhBqxjkLCAEh8AE0uTIF2HVueV0q6nVR6mG7s=; b=BOPdKsPmmV1LVL7sf1ainehfQrATPXtBEpJJzmrsn6nHZKE0WMn9+rDWhVEpItofWa UjMCnXSjtaiqkPYPoN/15WgzZtjPY5BGxXFxLAWpowSf5YXI3DPgJ46Rb97dP+J6RwYE MNwGq4vxvY002SUDCZqijMZMV2e3vZO5JU7Mb+f88eyvFphi8457WF42mqhrYhNktpbX E8hrsQJMnt9Cqm6AQbwhju951xHue3asdJKOwBU3LPRBOKQICO4qKA05VHnSXDsiLXPN SJ7H2rbvrcpginCZZCNTqZ6pNmg+tPmB/WcBbNwtjFqiTxIk/15PAAVbXZImDqhcZySD n0kQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=HhHEs84v; 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 z127-v6si2911157pgb.455.2018.07.02.15.45.54; Mon, 02 Jul 2018 15:46:09 -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=@linux-foundation.org header.s=google header.b=HhHEs84v; 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 S932291AbeGBWpO (ORCPT + 99 others); Mon, 2 Jul 2018 18:45:14 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:46845 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753560AbeGBWpN (ORCPT ); Mon, 2 Jul 2018 18:45:13 -0400 Received: by mail-io0-f194.google.com with SMTP id p7-v6so918ioh.13; Mon, 02 Jul 2018 15:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=caasTxZhBqxjkLCAEh8AE0uTIF2HVueV0q6nVR6mG7s=; b=HhHEs84veCw88c1UwnMiXLJ2yoHm+DOpQLXhyABI93GhemSNeIL0L9rbGYYQpYj25L jFZQNI+1Egkt7ViiKFlW9Xm2r2yk1i9YxnzBMOAMW4z0O8gNEkA48EpVH0Slvkcgd0cj RbqoIZnFrPsmGpS2fzwD7ap5nxuFS04Isnrks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=caasTxZhBqxjkLCAEh8AE0uTIF2HVueV0q6nVR6mG7s=; b=PFN144M3ySm12PgJIMXkgTZhr5NHeby8YyWqXfGeJwir07nFYWXmUHbdoiPVA1N+Ms gQcWVQlNoPpZaKwJAj8anzFgPbYKs3y9PZOb+ysw8y9fE8ArmK/mZvqyZqCjA14dZrrG 2wlIY/mV30hmlCmcR34yvxK7MeQcqlFe+WWcBBstT6RXV0pl2lkgFsMDpZIdCE065dJW XRnUcqQft3h6GQBvh4tMABo/EV8IOveeFruoBMBXB7oBAKIRSEgTr49zICYjlO5MU3LW 5vZ9JJ/qGqyapivfiTuWzuLpO9FegxniP7vqgGI9+YJ5GW6H7W4fvmUJ7Uadak+cfxGl P1Kg== X-Gm-Message-State: APt69E3sXYuh1aRimBVf6SkjnLslKJ7kdt0dICBWHe5l5mikiyYU+8To pV4i1zALfCB2M4dzqUO1xaGjtaoZtGGQPq0Q77s= X-Received: by 2002:a6b:980e:: with SMTP id a14-v6mr18313109ioe.238.1530571512395; Mon, 02 Jul 2018 15:45:12 -0700 (PDT) MIME-Version: 1.0 References: <20180702223143.4663-1-mathieu.desnoyers@efficios.com> In-Reply-To: <20180702223143.4663-1-mathieu.desnoyers@efficios.com> From: Linus Torvalds Date: Mon, 2 Jul 2018 15:45:01 -0700 Message-ID: Subject: Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs To: Mathieu Desnoyers Cc: Thomas Gleixner , Linux Kernel Mailing List , Linux API , Peter Zijlstra , Paul McKenney , Boqun Feng , Andy Lutomirski , Dave Watson , Paul Turner , Andrew Morton , Russell King - ARM Linux , Ingo Molnar , Peter Anvin , Andi Kleen , Christoph Lameter , Ben Maurer , Steven Rostedt , Josh Triplett , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes 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 On Mon, Jul 2, 2018 at 3:31 PM Mathieu Desnoyers wrote: > > Change the rseq ABI so rseq_cs start_ip, post_commit_offset and abort_ip > fields are seen as 64-bit fields by both 32-bit and 64-bit kernels rather > that ignoring the 32 upper bits on 32-bit kernels. This ensures we have a > consistent behavior for a 32-bit binary executed on 32-bit kernels and in > compat mode on 64-bit kernels. Actually, now that I see this again, I react to: > +static int check_rseq_cs_padding(struct task_struct *t) > +{ > + u32 pad; > + int ret; > + > + ret = __get_user(pad, &t->rseq->rseq_cs_padding); > + if (ret) > + return ret; > + if (pad) > + return -EINVAL; > + return 0; > +} This is all wrong. Just make "rseq_cs" be an __u64" too. That will clean up everything, and user space will have a much easier time filling it in too, since it's just one field. Instead of having to remember about the "let's fill in padding for 32-bit cases". Then the rseq_get_rseq_cs() will be __u64 rseq_cs; ret = get_user(rseq_cs, &t->rseq->rseq_cs); if (ret) return ret; ptr = (void *)rseq_cs; if (rseq_cs != (unsigned long)ptr) return -EINVAL; and it's all good, no #ifdef's etc needed. Hmm? Sorry for the bike-shedding, but this is now the last remaining user of that LINUX_FIELD_u32_u64, so let's just get rid of it entirely, ok? Then we can also get rid of that silly uapi/linux/types_32_64.h header file entirely. That would be *lovely*. Simpler code, simpler and less error-prone interfaces, and one less specialized header file. Linus