Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1262730yba; Tue, 2 Apr 2019 05:48:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqyL872+4ZWkAmpbKECMbprnKRcnG7YiOFQycQ/w1NEEo5vKwUakQBfSI9c8/ddpg/59EuJH X-Received: by 2002:a17:902:b686:: with SMTP id c6mr16264977pls.14.1554209318921; Tue, 02 Apr 2019 05:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554209318; cv=none; d=google.com; s=arc-20160816; b=GbszHuLhaPrIzALdWJWnM8soglkSzqYvfFFpNIdiHXIQC8D8EywYxbk1egCghQYULm slkDJTUSSQRCM9hbD3V8W2p5eSsRoopIpx0QcEI6cdETIB4fWVBoAF1WqjcWdZTd9za8 LfFUcqZ6isfaOu8Bd05Ql58mQHFe98NXQbgTFAYV3U8GE2oWmSQ7HJAM/d3ip7Mfnhou jKh6PyTZfDmbLXehDtMVPdBGUUGiJUvDHXkmgGm42PJd6Cxcm5XpipBpW+8AqiH6mzfd ylZFWAFMm4jRSrVFN2QnayvE7zjpORPn9XpkFSeHE6ZtpZK/2CMos85Ayn3eCIsOJmWA ZyTQ== 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=u3PSOHs4we7+LgIG6ZQZir4Fy57VqCCMcbhzYXQWknQ=; b=Ud7QdTKyCX16k2bVU9c6rxxbKUQ3lAOPG1yiXyNxf2l5QpbHLQso1f0bwElSNxiOi3 Hi5vDpH8ocuKTlr4XscN/sRKGDUc6y59bS1DGam90SwLwrtorq4LTIbyo6c82n1+U4ti hTKrWo7ucYV9l9egWR/NYM4UErP8j9v5Jw3fweTzDu86qgg/1aBxg28K7Ak2qVfEPPLI lmlAoYzwvILP2IPKEmOHnnFp9HeDhdXbq4KxbeuCcbUPuhDRCdnUu1WQSWXOPnkZD3n1 YPiE2KDMDUUjZdMPmHUntpRq6WdnD7YCBg3j5uY/mZZaBAh48OTRdmpCg2SRa1RLDWmd 3PTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RvtPBpLv; 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 89si11591572pld.265.2019.04.02.05.48.22; Tue, 02 Apr 2019 05:48:38 -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=RvtPBpLv; 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 S1730156AbfDBMrr (ORCPT + 99 others); Tue, 2 Apr 2019 08:47:47 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:38312 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729060AbfDBMrr (ORCPT ); Tue, 2 Apr 2019 08:47:47 -0400 Received: by mail-pf1-f193.google.com with SMTP id 10so6343271pfo.5 for ; Tue, 02 Apr 2019 05:47:46 -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=u3PSOHs4we7+LgIG6ZQZir4Fy57VqCCMcbhzYXQWknQ=; b=RvtPBpLvPglDtwnPF4yXUeK5oDlzVoAw9Ac/QiLLKSGbikn9e6229p73Q0tOoviq2D BavSCer7Dzqe0/C31mrVK/886gbUDYWuPnxHOlht2sOu/e62noERB05hR+v+Bbj+JICn Lb7g/8TOjfYKi5cKqi9tDj/4Gjl0w7oFGi+cz1GXwEAzmc5l0cphMO74o+wu5S8JjZik 7AqeS2RJ0S+0J5+xNSxMiTjPOKYRkB2DaefRCT/WCl4ZMTNyy1aYXf9qwji/GQQh7uA6 a4SkVWVDmZ28lLA5h47JmaNF3G6jNLy7QP3Ylvcw6DiwtS/xNNeagblhaZ/cgn7jvFfX OA/w== 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=u3PSOHs4we7+LgIG6ZQZir4Fy57VqCCMcbhzYXQWknQ=; b=ShlM67LGfjqp5N9CFgaT5mTBdcCdYEsFUeo+zQ8iqOUiaU5eRXDZLZXU2onsQbVvR5 Qn3OdwcHXKBNLFaMb1SZfnRwWfdVlrfTpFQIP7RXejMufEWaasht0iV8qq7i8AkMCmz6 wCTGQHP8pmF03o7KP/Df3r6vFw+94fSXkoTsUbwItIxXkL0zY7SwQrzUW15PZP75NGhz z88TfABfzSbDW8Cxc7A6h5TLicyn6c87kXbNbUk0lySJOm2/imc7hL/sW9JG/u7qdpHS ZPA3Xn9uNVD+PhrOCKkbLZ02COeaGjADHTE7FYzy0k8sloE+m2WbSzQxMjb+tKAtJEVp RcTA== X-Gm-Message-State: APjAAAW6dngLLW3aba95kJgyo/bLG4mKhP4vp/unfdbGYKIXJ0HrqDcd yK4nRKTw9FT6jr/p+iZfMSFDhmHwrOJ0Py+YlVNOvA== X-Received: by 2002:a65:6496:: with SMTP id e22mr52163844pgv.249.1554209265963; Tue, 02 Apr 2019 05:47:45 -0700 (PDT) MIME-Version: 1.0 References: <44ad2d0c55dbad449edac23ae46d151a04102a1d.1553093421.git.andreyknvl@google.com> <20190322114357.GC13384@arrakis.emea.arm.com> <20190328141934.38960af0@gandalf.local.home> <20190329103039.GA44339@arrakis.emea.arm.com> In-Reply-To: <20190329103039.GA44339@arrakis.emea.arm.com> From: Andrey Konovalov Date: Tue, 2 Apr 2019 14:47:34 +0200 Message-ID: Subject: Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls To: Catalin Marinas Cc: Steven Rostedt , Will Deacon , Mark Rutland , Kees Cook , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Vincenzo Frascino , Eric Dumazet , "David S. Miller" , Alexei Starovoitov , Daniel Borkmann , Peter Zijlstra , Arnaldo Carvalho de Melo , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Linux ARM , Linux Memory Management List , linux-arch , LKML , Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Ruben Ayrapetyan , 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 Fri, Mar 29, 2019 at 11:30 AM Catalin Marinas wrote: > > (I trimmed down the cc list a bit since it's always bouncing) > > On Thu, Mar 28, 2019 at 02:19:34PM -0400, Steven Rostedt wrote: > > On Thu, 28 Mar 2019 19:10:07 +0100 > > Andrey Konovalov wrote: > > > > > > > Signed-off-by: Andrey Konovalov > > > > > --- > > > > > ipc/shm.c | 2 ++ > > > > > mm/madvise.c | 2 ++ > > > > > mm/mempolicy.c | 5 +++++ > > > > > mm/migrate.c | 1 + > > > > > mm/mincore.c | 2 ++ > > > > > mm/mlock.c | 5 +++++ > > > > > mm/mmap.c | 7 +++++++ > > > > > mm/mprotect.c | 1 + > > > > > mm/mremap.c | 2 ++ > > > > > mm/msync.c | 2 ++ > > > > > 10 files changed, 29 insertions(+) > > > > > > > > I wonder whether it's better to keep these as wrappers in the arm64 > > > > code. > > > > > > I don't think I understand what you propose, could you elaborate? > > > > I believe Catalin is saying that instead of placing things like: > > > > @@ -1593,6 +1593,7 @@ SYSCALL_DEFINE3(shmat, int, shmid, char __user *, shmaddr, int, shmflg) > > unsigned long ret; > > long err; > > > > + shmaddr = untagged_addr(shmaddr); > > > > To instead have the shmaddr set to the untagged_addr() before calling > > the system call, and passing the untagged addr to the system call, as > > that goes through the arm64 architecture specific code first. > > Indeed. For example, we already have a SYSCALL_DEFINE6(mmap, ...) in > arch/arm64/kernel/sys.c, just add the untagging there. We could do > something similar for the other syscalls. I don't mind doing this in the > generic code but if it's only needed for arm64, I'd rather keep the > generic changes to a minimum. Do I understand correctly, that I'll need to add ksys_ wrappers for each of the memory syscalls, and then redefine them in arch/arm64/kernel/sys.c with arm64_ prefix, like it is done for the personality syscall right now? This will require generic changes as well. > > (I had a hack overriding __SC_CAST to do this automatically for pointer > arguments but this wouldn't work on mmap() and friends as the argument > is unsigned long) > > -- > Catalin