Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp970673imm; Fri, 29 Jun 2018 09:13:28 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc4SNjVN92bWk2zx7Mo/F37rD7/j6Lt7iP4G8pxxqw6GF0hNO0N5b9colgqbv58ohywUE5b X-Received: by 2002:a65:614a:: with SMTP id o10-v6mr1834845pgv.387.1530288808259; Fri, 29 Jun 2018 09:13:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530288808; cv=none; d=google.com; s=arc-20160816; b=quDtHc5/w6NAVgPUuXsc+f2MDVOhhFOvM9SVz3cdOXcHgkaQksCM+pt6WuyumzMNjM krWVRd43z2fJQES1W6YHCr/TkfHO0EJ/tSncd5eX6fmyqSoW0lnN8bO3dNkBLE8KUro9 Okcds16Mzaum/NCVXxcbPR673is6MXBihybRNPNc7PYuyd5zx7n3xIAWIFAjCqpkldc9 ogNswsnar8QtLjKL5zs1mmICQhbRvbcGyAZ7zdH7/J/zHyaP+/kLak/Jf8R8u7Hbd236 8cENagmQkSqOyoAspGeZIVVFH/I519V1GRNYDJLjG8MNSgeW7CJ3k5fmw/4sMVmFC803 jjeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter :arc-authentication-results; bh=E4WIywRkT6q1+sgTnr5yUnx4yaTA5nWtQ+BnOJ+uCZA=; b=Oow++buF9QxnV1Ia7J5EjaO9i3DBvZ6CMbGWozg9P15JQoalA0iNfqxPy7uo0Qj255 J1hYzP828ZHXBnoN2Bt06CS1/W57RwaY2PJZ+5NsR6+ZkjEJla8O8gtwRNOdZL4MHeCq emHhh6TiyKHKU6D3MsV+CZiEKfOtHWjNCfU1WpAHGr+hoTjAVR7+kxwMtr4JHg9ni/qw rrIc2KJuCnqEkP/O4Ai6qBK5OhEqIbpXxzAksPDSctpGsf7hIcwgQbND3xlz1RJUTXgh dAEOX4PLavcOW/Smn0swKJYkKXgdUZpUNW7TYzZwGKsHwM25O+yi/VhJSUGikKft+idt f7aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=RBK3FiRD; 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=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l4-v6si9521896plb.213.2018.06.29.09.13.13; Fri, 29 Jun 2018 09:13:28 -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=@efficios.com header.s=default header.b=RBK3FiRD; 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=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934618AbeF2Nzr (ORCPT + 99 others); Fri, 29 Jun 2018 09:55:47 -0400 Received: from mail.efficios.com ([167.114.142.138]:55670 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802AbeF2Nzp (ORCPT ); Fri, 29 Jun 2018 09:55:45 -0400 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 5B67C22D097; Fri, 29 Jun 2018 09:55:44 -0400 (EDT) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id CfE0YLhB3LtQ; Fri, 29 Jun 2018 09:55:43 -0400 (EDT) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id CE70622D094; Fri, 29 Jun 2018 09:55:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com CE70622D094 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1530280543; bh=E4WIywRkT6q1+sgTnr5yUnx4yaTA5nWtQ+BnOJ+uCZA=; h=Date:From:To:Message-ID:MIME-Version; b=RBK3FiRDd6DduOJ9Vrr2hf7sn/NCPjtF+5scTuOKqeqx2K9SRegSTVDvEYlLALnPt 8uMAtCmowuCHDX6DyWHYqW2KpqMNh/zWJpccS/3bhNvWUglUfu98zU37qsGXrQMPC5 H5yfXaUifH00mNZvnYiMFQ9FDnD1Ra3C00V/MdC2zK6H+ddmioYDauZ6SpE7elgyyU RK1Q4kv2Wg4KfgtWg2q5LmamT7gHlJ3LkyepuERraOMbeULjFzGzz1RiBDY3OOw7CW iSL+9GwIi6PKhJyWTX6u0MecDP1Lgp8/yY+Nf3izMSZjEfQHAg49RTirFgXj46gI0h ++Ndls24nOHuQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id fU8TQKLBSMrq; Fri, 29 Jun 2018 09:55:43 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id B32F522D08D; Fri, 29 Jun 2018 09:55:43 -0400 (EDT) Date: Fri, 29 Jun 2018 09:55:43 -0400 (EDT) From: Mathieu Desnoyers To: Andy Lutomirski Cc: Linus Torvalds , Thomas Gleixner , linux-kernel , 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 , rostedt , Josh Triplett , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes Message-ID: <820874666.9567.1530280543568.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20180628162359.9054-1-mathieu.desnoyers@efficios.com> Subject: Re: [RFC PATCH for 4.18 1/2] rseq: validate rseq_cs fields are < TASK_SIZE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.8_GA_2096 (ZimbraWebClient - FF52 (Linux)/8.8.8_GA_1703) Thread-Topic: rseq: validate rseq_cs fields are < TASK_SIZE Thread-Index: M/QysoCtxfYa/h1k7UmBXhz0Y8lILQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 28, 2018, at 7:29 PM, Andy Lutomirski luto@kernel.org wrote: > On Thu, Jun 28, 2018 at 2:22 PM, Linus Torvalds > wrote: >> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote: >>> >>> 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; } >> >> We already have that. It's called "user_addr_max()". > > Nah, that one is more or less equivalent to TASK_SIZE_MAX, except that > it's different if set_fs() is used. So which one would be right in this case ? AFAIU we want to ensure we don't populate regs->ip with a bogus address that would make SYSRET or other return to userspace instructions explode. Is that guaranteed by TASK_SIZE or TASK_SIZE_MAX (aliased by user_addr_max()) ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com