Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp455931ybh; Mon, 20 Jul 2020 22:39:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4nysuYwW/KuK6dXIjfKfkE2ZGxY4SJLlVSk5tujWDnhWwmitXX3Wzmoz/7lRpescSCY8K X-Received: by 2002:a17:906:2e06:: with SMTP id n6mr23413998eji.34.1595309955007; Mon, 20 Jul 2020 22:39:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595309955; cv=none; d=google.com; s=arc-20160816; b=xPVvfZIL+GOdKcMQmedX3B2ypRwiAu/sRBZuf9+l7HAXWZYMM3Nv4/GLd+oZA9SA+w C9wAa5U3c8zW+0vxe2QYbI1+JhKtgnPm+8el6e8Iguag+W8g/1d9yymAHFseEMnoM10o 4gzBTeEyWsJrNHyHkk6RpzmPD1MpmT/WvQIipLxnqe8CXqCbgwSjtRjzTbi+XAkfn7mV twxeCjXSAsGP+QxMeU0XZwITOWAkfKeOL9gIOMWWjwbDUtm13t5t6WYlk2OsnCNw1vRU J7gv3rStYgI9+NbILi4zmJPHUNmK4LLnzAmsKls9BKDx/4an/NKY0Zqt97y1uP80yP3l HOBg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=wY+i8y9FIBxSNuDk6T9nQ6VOBEQLR5DBEzMWtRQ4fvU=; b=ZgLNIO3NyacG3Pa3uGfQXk4yJbMBlpZwMN1SbZ23At5wNauh7r41M0Bh7bO0wqxV5N R1VqryEL8WPNqUCs8Yk0ZbvrrynQsM7ETmck9sSO/FqAD042zz/SNS84YyCEOb0SB6di jqLbphbBMB8fC9EaExqEfYZDqyUgn87ExVF6CwhUrZEhjTHJ5QtVW126yeMcw2pB2zzP h2U4drkcU0DXGkfxgjuEVAAb6aZSlJZZ6+KEk8SRME6HPmSSVu2hY/lNWDgPMKr2x5g4 w/joZiwvyuNHyQr4S79gYDkclA8Kezt8bNraWmvTShU12vCY3Qz5wO+MOEOEv/OD0/79 48hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nb1si11427684ejb.565.2020.07.20.22.38.52; Mon, 20 Jul 2020 22:39:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727972AbgGUFfq (ORCPT + 99 others); Tue, 21 Jul 2020 01:35:46 -0400 Received: from verein.lst.de ([213.95.11.211]:50620 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbgGUFfq (ORCPT ); Tue, 21 Jul 2020 01:35:46 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 78C446736F; Tue, 21 Jul 2020 07:35:42 +0200 (CEST) Date: Tue, 21 Jul 2020 07:35:42 +0200 From: Christoph Hellwig To: Guenter Roeck Cc: Christoph Hellwig , Nick Hu , Greentime Hu , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Andrew Morton , Linus Torvalds , linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check Message-ID: <20200721053542.GA10301@lst.de> References: <20200714105505.935079-1-hch@lst.de> <20200714105505.935079-2-hch@lst.de> <20200718013849.GA157764@roeck-us.net> <20200718094846.GA8593@lst.de> <20200720221046.GA86726@roeck-us.net> <20200721045834.GA9613@lst.de> <20200721052022.GA10011@lst.de> <7fc565fe-411e-6a0b-8aaf-0bf808f0d6a9@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7fc565fe-411e-6a0b-8aaf-0bf808f0d6a9@roeck-us.net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 20, 2020 at 10:30:30PM -0700, Guenter Roeck wrote: > Guess I lost it somewhere. Are you saying the check was wrong all along > and your patch fixed it ? Oh, it is a little complicated. Normally we have two address space limits, KERNEL_DS and USER_DS, and they are supposed to be different. armnommu and m68k define them to the same value for no good reason. That leads to: uaccess_kernel always returning true as it does a positive check agains KERNEL_DS, which disables a bunch of drivers like sg and rdma, and could also lead to really strange and probably broken results in a few places. It also leads to the SIGKILL in addr_limit_user_check never triggering due to the negatŃ–ve check, which is ok as the limits never are different.