From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0DDDC04AB4 for ; Fri, 17 May 2019 14:49:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 81E102166E for ; Fri, 17 May 2019 14:49:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qSYpn0qU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81E102166E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7sUiYsAJXa17bGFlKmI31i19kM/or+a2LVc8pwnVkf0=; b=qSYpn0qUe+xraW RTZabgHaRZDqTawVrQIox8pSE6FeejVxRpXaL4o1xyqOWBbAbubk6bNVIsJBKMG1rs0j9HQ8/XCWN us4z3i1AXy5tYnMmf9jRDd91q6TM/FTLlI40oU7Y8Nh6qcDkz6rtm3HcH6OxNCsRzc1CJtk1XuwX/ kzCfVXSD7qTSpTlzjX9Ee5tTwsxxLEOSk691mFdbZFPSGjie93J/9XGtvT1NLk6ooQFnw4TrXreUJ zYtsD6XVzE8U5AYM31F8jblYAON9MvMy6DsKo8qIUzZzPqeRv9z6gioBEvVdDDXI+cJWfZGHB2H8S nqqGgPLUOd61iYgXZqJg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hReBA-0006rj-UN; Fri, 17 May 2019 14:49:48 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hReB6-0006q9-Co for linux-arm-kernel@lists.infradead.org; Fri, 17 May 2019 14:49:46 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C624E1715; Fri, 17 May 2019 07:49:39 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3BA583F71E; Fri, 17 May 2019 07:49:34 -0700 (PDT) Date: Fri, 17 May 2019 15:49:31 +0100 From: Catalin Marinas To: Andrey Konovalov Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Message-ID: <20190517144931.GA56186@arrakis.emea.arm.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190517_074944_525396_FA59EBBE X-CRM114-Status: GOOD ( 20.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Felix Kuehling , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Dave Martin , Evgeniy Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Alex Williamson , Mauro Carvalho Chehab , linux-arm-kernel@lists.infradead.org, Kostya Serebryany , Greg Kroah-Hartman , Yishai Hadas , linux-kernel@vger.kernel.org, Jens Wiklander , Lee Smith , Alexander Deucher , Andrew Morton , Robin Murphy , Christian Koenig , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Andrey, On Mon, May 06, 2019 at 06:30:46PM +0200, Andrey Konovalov wrote: > One of the alternative approaches to untagging that was considered is to > completely strip the pointer tag as the pointer enters the kernel with > some kind of a syscall wrapper, but that won't work with the countless > number of different ioctl calls. With this approach we would need a custom > wrapper for each ioctl variation, which doesn't seem practical. The more I look at this problem, the less convinced I am that we can solve it in a way that results in a stable ABI covering ioctls(). While for the Android kernel codebase it could be simpler as you don't upgrade the kernel version every 2.5 months, for the mainline kernel this doesn't scale. Any run-time checks are relatively limited in terms of drivers covered. Better static checking would be nice as a long term solution but we didn't get anywhere with the discussion last year. IMO (RFC for now), I see two ways forward: 1. Make this a user space problem and do not allow tagged pointers into the syscall ABI. A libc wrapper would have to convert structures, parameters before passing them into the kernel. Note that we can still support the hardware MTE in the kernel by enabling tagged memory ranges, saving/restoring tags etc. but not allowing tagged addresses at the syscall boundary. 2. Similar shim to the above libc wrapper but inside the kernel (arch/arm64 only; most pointer arguments could be covered with an __SC_CAST similar to the s390 one). There are two differences from what we've discussed in the past: a) this is an opt-in by the user which would have to explicitly call prctl(). If it returns -ENOTSUPP etc., the user won't be allowed to pass tagged pointers to the kernel. This would probably be the responsibility of the C lib to make sure it doesn't tag heap allocations. If the user did not opt-in, the syscalls are routed through the normal path (no untagging address shim). b) ioctl() and other blacklisted syscalls (prctl) will not accept tagged pointers (to be documented in Vicenzo's ABI patches). It doesn't solve the problems we are trying to address but 2.a saves us from blindly relaxing the ABI without knowing how to easily assess new code being merged (over 500K lines between kernel versions). Existing applications (who don't opt-in) won't inadvertently start using the new ABI which could risk becoming de-facto ABI that we need to support on the long run. Option 1 wouldn't solve the ioctl() problem either and while it makes things simpler for the kernel, I am aware that it's slightly more complicated in user space (but I really don't mind if you prefer option 1 ;)). The tagged pointers (whether hwasan or MTE) should ideally be a transparent feature for the application writer but I don't think we can solve it entirely and make it seamless for the multitude of ioctls(). I'd say you only opt in to such feature if you know what you are doing and the user code takes care of specific cases like ioctl(), hence the prctl() proposal even for the hwasan. Comments welcomed. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel