Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp2610470ybm; Thu, 23 May 2019 21:25:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJ2LlQxSYSyGAVn2tK6KG270V4PttIyQKBSoYWgi4OtSmZzG3+OdaXCKjcm5Wm7RL4M13H X-Received: by 2002:a17:90a:be13:: with SMTP id a19mr6431951pjs.86.1558671909094; Thu, 23 May 2019 21:25:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558671909; cv=none; d=google.com; s=arc-20160816; b=Mx881FdDlNCeg8zmYXIG9LSHfrqHOeLf5SiUBgibeWJqTX4sLCeNRRsMV0DUREs6Kf dlx95+yR3p6w8PVCCBfkpXJ/CkxQ90KfnJQU64k7ueyQDYAeXQj07C1hQfzkQhWaBpjb UA5/B+LWhkvop0M/pVdA7U+xvB2CuLNVjogV5zpsDaszQ3F0E/SIz7Dg12OoDI+ugeMW U1kafxTF4G5VVe5v5cgzXXZk4VvFVBrntkIjdwfEohedbhSgC0b6Dp/d5cUYDywGZqJv SiL3cQmJDMzBen5C3F9lR7ZFdnQgfjdDuuK1fxKzBSlVBsnUZJtQeMN00I6rt9Wc2meS tEyQ== 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; bh=xAYnRWw3Tu8/93j9I1Decyj4SiwalEXjnp8HjDGWVMk=; b=LsgdN2cCzPfNrW1pEij/yXSr78UeXrPUUYMYbW6VcAj2+S0jidKnBLLBUcwnkDLU5x g9vn2WhVL8BWx4AIduN9O04WPH8EBjEouS6C0uuciyQLlx+7XvzgywZ95mW0wrQpf6Ln PA2po1dF1tws7z44EerR7cSCNmafazmC9LBGBj3CHZDz/r+LmVcocsznEtPfQL0SGks/ EUWXVSucM4sRWIcHEgLxoTDVMVz7/BJWj94U/HzxsRxKA2mgXPe5SZGD64tldcD0geh3 oo9qkDFS+XSoClBt2L5xEvmnywirJbocRSL1NYDmcBd8WshMFHqezBzyqtG7QjJ6tKH1 +bpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WnRK49CE; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i3si2357033pgq.440.2019.05.23.21.24.49; Thu, 23 May 2019 21:25: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=@google.com header.s=20161025 header.b=WnRK49CE; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731824AbfEXEXZ (ORCPT + 99 others); Fri, 24 May 2019 00:23:25 -0400 Received: from mail-ua1-f65.google.com ([209.85.222.65]:42647 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726308AbfEXEXY (ORCPT ); Fri, 24 May 2019 00:23:24 -0400 Received: by mail-ua1-f65.google.com with SMTP id e9so3033841uar.9 for ; Thu, 23 May 2019 21:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xAYnRWw3Tu8/93j9I1Decyj4SiwalEXjnp8HjDGWVMk=; b=WnRK49CElZNooeneU/rmiXD4MNL+NGJ+1q+LoLrd8r1BWPG0vFLLn5srrzAwJdtZCr YNvRiKrpydE8yY/WwhILnly3Zvune3jCfbXw7GsuMvu4P+dyMtapEbIZ2jkKw+bAAaZT /NstjIQP+l4nVYqupG3KK3t/H/Zt2rSh8UshTl0ZeyMDpnbmZlbVjVV+q+S0iwZ4uNET wEULW4QLu8xXLGSpfqZElCLKOXZT2Zp/eFOfWYxNKR73Qs1kFKXoJK7Lexkh9qJC8nqp yZ2rrh8i3toWpfjsayQpALHrdDwRoiqV6AXbdW6lkKZym6fAr2YHiokI7QWgzJYQeySd EWQQ== 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=xAYnRWw3Tu8/93j9I1Decyj4SiwalEXjnp8HjDGWVMk=; b=Cl+m4cM/Pm1R4DCcf8TKZRLHbNvWl2n1iBCyExsjPUcvVoViDPwZRfL8fsuBvszwOe JseYdDJzwfy5Vsp2KHHD3QKnfm5xhd6FpzJPfcqRvcYF6p9I9WkwRrBccGnfwy+WkEWn RHxrD3Jcogx/wXC7JjNGze3wcRRuuNJQltSdJPgc+CnY93IIo21rsuUFpjPkgzoqfzkQ 9j8tr239BcispwN0A+5T0LULNPeiRl7a6NfgQF71dvq609XkEeiD/uTDElBVz1G4Ev5z Ja/xCcjaMIJ1x6xNCW/eduHA/dueC4DRqge2ZFTquenXLk+7fHOEL+PzYll2SFjh2H3C tWtA== X-Gm-Message-State: APjAAAWpekNkPFeHEJg0lyicz+qrnZfvIOfwmm7fDHinpjzZIW69+FOn bcsLqxzo8WdRasuGGKtK6MbAawi2UnRtYrjnELyIww== X-Received: by 2002:ab0:3109:: with SMTP id e9mr449008ual.66.1558671802883; Thu, 23 May 2019 21:23:22 -0700 (PDT) MIME-Version: 1.0 References: <00eb4c63fefc054e2c8d626e8fedfca11d7c2600.1557160186.git.andreyknvl@google.com> <20190522114910.emlckebwzv2qz42i@mbp> <20190523090427.GA44383@arrakis.emea.arm.com> In-Reply-To: <20190523090427.GA44383@arrakis.emea.arm.com> From: Evgenii Stepanov Date: Thu, 23 May 2019 21:23:13 -0700 Message-ID: Subject: Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls To: Catalin Marinas Cc: Andrey Konovalov , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Kees Cook , Yishai Hadas , Felix Kuehling , Alexander Deucher , Christian Koenig , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Leon Romanovsky , Dmitry Vyukov , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Robin Murphy , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy 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, May 23, 2019 at 2:04 AM Catalin Marinas wrote: > > On Wed, May 22, 2019 at 02:16:57PM -0700, Evgenii Stepanov wrote: > > On Wed, May 22, 2019 at 4:49 AM Catalin Marinas wrote: > > > On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote: > > > > This patch is a part of a series that extends arm64 kernel ABI to allow to > > > > pass tagged user pointers (with the top byte set to something else other > > > > than 0x00) as syscall arguments. > > > > > > > > This patch allows tagged pointers to be passed to the following memory > > > > syscalls: brk, get_mempolicy, madvise, mbind, mincore, mlock, mlock2, > > > > mmap, mmap_pgoff, mprotect, mremap, msync, munlock, munmap, > > > > remap_file_pages, shmat and shmdt. > > > > > > > > This is done by untagging pointers passed to these syscalls in the > > > > prologues of their handlers. > > > > > > I'll go through them one by one to see if we can tighten the expected > > > ABI while having the MTE in mind. > > > > > > > diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c > > > > index b44065fb1616..933bb9f3d6ec 100644 > > > > --- a/arch/arm64/kernel/sys.c > > > > +++ b/arch/arm64/kernel/sys.c > > > > @@ -35,10 +35,33 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, > > > > { > > > > if (offset_in_page(off) != 0) > > > > return -EINVAL; > > > > - > > > > + addr = untagged_addr(addr); > > > > return ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT); > > > > } > > > > > > If user passes a tagged pointer to mmap() and the address is honoured > > > (or MAP_FIXED is given), what is the expected return pointer? Does it > > > need to be tagged with the value from the hint? > > > > For HWASan the most convenient would be to use the tag from the hint. > > But since in the TBI (not MTE) mode the kernel has no idea what > > meaning userspace assigns to pointer tags, perhaps it should not try > > to guess, and should return raw (zero-tagged) address instead. > > Then, just to relax the ABI for hwasan, shall we simply disallow tagged > pointers on mmap() arguments? We can leave them in for > mremap(old_address), madvise(). I think this would be fine. We should allow tagged in pointers in mprotect though. > > > With MTE, we may want to use this as a request for the default colour of > > > the mapped pages (still under discussion). > > > > I like this - and in that case it would make sense to return the > > pointer that can be immediately dereferenced without crashing the > > process, i.e. with the matching tag. > > This came up from the Android investigation work where large memory > allocations (using mmap) could be more efficiently pre-tagged by the > kernel on page fault. Not sure about the implementation details yet. > > -- > Catalin