Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp361666imm; Thu, 28 Jun 2018 22:12:53 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfuh4b9uYj/gUagIlUGu+AWJw9BFI99xsHq1um2X1Wc51RQ6TwReSje+QWlDLah92p4jcFA X-Received: by 2002:a65:5286:: with SMTP id y6-v6mr10353848pgp.65.1530249173649; Thu, 28 Jun 2018 22:12:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530249173; cv=none; d=google.com; s=arc-20160816; b=MXD571pycfY80YFmR1tuQCGKlU3YGmElc64LavfHZdK2EHi289GqDbPE5J6ei5QTc9 yzNylRKh6utprc/r6AhlW3wcLLbAoMLZMgjRdJSH7DtdM9/g0nZWt4CHn0WWBSqrCxYP jmM7QiSH6W8aKxZ0CIK9B6tbYR/a+pKehR/91SA19cUVTiLgg9d6jl8+c48tIh5dkHo3 qDhy5OwgyCYalKZQSANqD86iFgjyUBkUAedMy1jcS6YQBzwSAaerTwJWAN8vfzl37vY6 yN0HWV3sDhYZ9IEME+kNPY4ewH6e+0jhai3Gf8ZM0oS0JPtvdYap31eDCpDKSmQw3mIw I/xA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=+A6hWlNawzMs9S7/Cqv6ihLeI9u4FmM2P7+YGcXChVw=; b=sIigE12Z79c/ymUR8cPEGi3/swDSvIX8kSzP2MEQadA30K/2r+j75j+qn+MjulS+jj 27p9+2a5QFnsTYGGW4DeGKoPTr+gOAJzjtpdSj7MG1WRuNz4JYuJpbNKWn1vC6mOiJ2L /AXY1+jzGKWO2/I4oNhVa4wG0sD5Dq6GG1vFgiP7K8ht/7KeCUcGNEsYdJTGYHnRt72I 2KM4w62iHQ2BkgmDwGqI0oCGvp48G68WqQimRrBusz4zw71C227sEhqMlW8+3IsV3HQa krv9aFYc5LL6y7Nd1oRe+K2SZ1PDsDAF4p8Wni1/CAMIYogo27Zu00ZDCYGYXlubqFZ4 W9QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AeXNvAKS; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1-v6si7892168plt.389.2018.06.28.22.12.39; Thu, 28 Jun 2018 22:12:53 -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=@kernel.org header.s=default header.b=AeXNvAKS; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966006AbeF1UXD (ORCPT + 99 others); Thu, 28 Jun 2018 16:23:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:34112 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752881AbeF1UXB (ORCPT ); Thu, 28 Jun 2018 16:23:01 -0400 Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF8F327921 for ; Thu, 28 Jun 2018 20:23:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1530217381; bh=3uR/svpXwiY3T1jMgHIraI2J27+mcsWt0eEAkXT6Ynw=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=AeXNvAKSD5SmlZ2Acd3T49BfJNQ91gE98fLa1YFNnSyCYj8OxUk6lSlSTIRqlbchg 4p1HPsrqdyUmBZYMnAGKrVuBORSvh75swyfKjzRo0CmZ6c0LsDRB0U/AuMfMZ8bAnn c8dioRdpVKhA5I0Pb/IbysKij/QEuRB/vSuAbnYs= Received: by mail-wm0-f46.google.com with SMTP id z137-v6so10356620wmc.0 for ; Thu, 28 Jun 2018 13:23:00 -0700 (PDT) X-Gm-Message-State: APt69E15CC+T+CuoNKf+x7irmd1QGQqy9MtyZRVMPN2bn6Lf0zBizR9f 55YVDBAJlhepgQtNxecFZpdV9gckcANNE9qg5Rva/Q== X-Received: by 2002:a1c:4a9d:: with SMTP id n29-v6mr8690665wmi.46.1530217379095; Thu, 28 Jun 2018 13:22:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:7e92:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 13:22:38 -0700 (PDT) In-Reply-To: <20180628162359.9054-1-mathieu.desnoyers@efficios.com> References: <20180628162359.9054-1-mathieu.desnoyers@efficios.com> From: Andy Lutomirski Date: Thu, 28 Jun 2018 13:22:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE To: Mathieu Desnoyers Cc: Thomas Gleixner , LKML , Linux API , Peter Zijlstra , "Paul E . McKenney" , Boqun Feng , Dave Watson , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H . Peter Anvin" , Andi Kleen , Chris Lameter , Ben Maurer , Steven Rostedt , Josh Triplett , Linus Torvalds , 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 Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers wrote: > Validating the abort_ip field of rseq_cs ensures that the kernel don't > return to an invalid address when returning to userspace after an abort. > I don't fully trust each architecture code to cleanly deal with invalid > return addresses. > > Validating the range [ start_ip, start_ip + post_commit_offset ] is an > extra validation step ensuring that userspace provides valid values to > describe the critical section. > > If validation fails, the process is killed with a segmentation fault. > > 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. This is okay with me for a fix outside the merge window. Can you do a followup for the next merge window that fixes it better, though? In particular, TASK_SIZE is generally garbage. I think a better fix would be something like adding a new arch-overridable helper like: static inline unsigned long current_max_user_addr(void) { return TASK_SIZE; } and overriding it on x86 as something like: static inline unsigned long current_max_user_addr(void) { #ifdef CONFIG_IA32_EMULATION return user_64bit_mode(current_pt_regs()) ? TASK_SIZE_MAX : (1UL << 32) - 1; #else return TASK_SIZE_MAX; } TASK_SIZE really needs to die.