Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp668041img; Tue, 26 Feb 2019 06:42:42 -0800 (PST) X-Google-Smtp-Source: AHgI3IY3W67pHcdGw8X6BLJHCEgl0XKA+6ISN0UsuZR4C3hLZBd3vdkgRjH3DiWeagFeIU97tZL7 X-Received: by 2002:a17:902:9a43:: with SMTP id x3mr26109753plv.173.1551192162217; Tue, 26 Feb 2019 06:42:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551192162; cv=none; d=google.com; s=arc-20160816; b=rCXg6JUQ52PWFHTAAEMXmS+z5vTCmBVfovARj7O6KAGuQmAlRGLuikJoagwCCkFmET +JUWRkRjSIPY+CW9SF+3BSmg/bD1fdNLtDBVQhyKOl6l9toiUwzrCbREqRi6Ah2Hrs1D YR7bpNGQB9CYHlH1RzmXGiEdg8dn+A0IpuA+KDq3ZOspNiuls2CgN19vE1gX9CLG7lwd unZanxPwrAzIN5lJtTxHdpUNS2mLbNPz++B46hnGlTGQeCXzFisUgxLCldG+wzlYNZ6L rbL84GvvCw4X2nfh4A8al02oqdcHCEBY2z+tvWbYdEAhfDOdmma54ufinuU3e8OK9wa5 R78A== 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=ORID1v1ozYXyKv1mw/ofFm5kiuOuJ/TBoHbnGpDrQY0=; b=E+8URWRovqA5TCZe//twzPCGY+J4YV2bPWga0Z66aE5tyFSxkorfMjSPF+pHtLvu1n VeSCuDY5T16bZPOw58/YNxIQ/0p//7R7s0aYZzSEAdNvtWS3WGPQFRY0CbVm0uz5+JTE oTwPbSYuHP8ebZwolQojb868LyjWE8xKHqZhhL2ySEnhLv6g5LEbRmkYoyTd93kUU/GJ xGdNlSeC3p2dl3RjvDTDOrb0pgxOgHeqDSW+B1E97lP8vqvbPJlGXS8j9zwZdtZtBRHR 8lqqQ4yVfy++WjCKoB2qXIYBqHUZ9VIXuVJy03fdXgeaEAcfMTFPacBwczJb+FTZKYnx cBqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="Jk4s/BkF"; 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 x6si12709666pfm.219.2019.02.26.06.42.27; Tue, 26 Feb 2019 06:42:42 -0800 (PST) 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="Jk4s/BkF"; 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 S1727662AbfBZOlj (ORCPT + 99 others); Tue, 26 Feb 2019 09:41:39 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:35848 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726810AbfBZOli (ORCPT ); Tue, 26 Feb 2019 09:41:38 -0500 Received: by mail-pf1-f196.google.com with SMTP id n22so6350709pfa.3 for ; Tue, 26 Feb 2019 06:41:38 -0800 (PST) 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=ORID1v1ozYXyKv1mw/ofFm5kiuOuJ/TBoHbnGpDrQY0=; b=Jk4s/BkFrIcxrk4e9Mx5smnm1MMtapGUCpafH868xdIWYkLK7M78NPFfkO1hXlBR3s fHSFCSGQY90XYaDQqb63dSKPREtSbEi2GwRgT00jYvnEy0yQetugEzlFqBmtB3qipsAd q/rhOJ6CKsqxpXxBDrJDcb0ls8JRx8hPmbNL5pXQCFMY5+3weHhsnBcu5hbxiUG4WqQl pBEq1Wji+wh6z+8emU3AosXH6snGNQBpu8akU3FP96jjwWcneLVMTgn776abphESvY54 iMhXTsCqkSEIu1VQDJchEorqdn4d1RpFfWm51ZaV3ypfOUhUpwNhpwhi50tHIgnGBRqu SjeQ== 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=ORID1v1ozYXyKv1mw/ofFm5kiuOuJ/TBoHbnGpDrQY0=; b=ExrEMD8pP9CBXgFsH3ljIlh/XL4tUvqHOLBhr8FEP/dKPwX5gezZoKTjO0B7y3aE4E pmu1XSYNGOY83V1tUyGI9gkk7HoAstcMYtKLxc3ytWQMzR7uznuiZVIoEhuE8Hg3JgJs +Qx6yHQPTQ3sn5NhoFpFPCjFWaF9Wijf53W02aoiauN+fqaInlrEc4Tn9RaC2CEBz4wh iAttNBJrRs1H3jYf0ieyMHTpk+7XyHWawLswMd3XGm9BjNv5+HFfJ6+GUouRHA4gXjG4 CQ2zls40XKLHXWW5ZcIZZe9s1x50HCK7fngJO7kqDwLacgsoGR6NKd8FVuBqDkG2VOnN F2Iw== X-Gm-Message-State: AHQUAuZFynhPehQB6ggo5YAO0TR5Gxh+SH29C0RSO9iyZlGvKyDu7G3j PID4GW6Xk/wOwl9DN9xm4DoqtVPIzzgA0D4edYq/lA== X-Received: by 2002:a62:4299:: with SMTP id h25mr26113838pfd.165.1551192097850; Tue, 26 Feb 2019 06:41:37 -0800 (PST) MIME-Version: 1.0 References: <3875fa863b755d8cb43afa7bb0fe543e5fd05a5d.1550839937.git.andreyknvl@google.com> <81ea4e77-90a4-4fd9-2bc8-135e0da30044@intel.com> In-Reply-To: <81ea4e77-90a4-4fd9-2bc8-135e0da30044@intel.com> From: Andrey Konovalov Date: Tue, 26 Feb 2019 15:41:26 +0100 Message-ID: Subject: Re: [PATCH v10 04/12] mm, arm64: untag user pointers passed to memory syscalls To: Dave Hansen Cc: Catalin Marinas , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Vincenzo Frascino , Linux ARM , "open list:DOCUMENTATION" , Linux Memory Management List , linux-arch , "open list:KERNEL SELFTEST FRAMEWORK" , LKML , Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Chintan Pandya , 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 Sat, Feb 23, 2019 at 12:07 AM Dave Hansen wrote: > > On 2/22/19 4:53 AM, Andrey Konovalov wrote: > > --- a/mm/mprotect.c > > +++ b/mm/mprotect.c > > @@ -578,6 +578,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len, > > SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len, > > unsigned long, prot) > > { > > + start = untagged_addr(start); > > return do_mprotect_pkey(start, len, prot, -1); > > } > > > > @@ -586,6 +587,7 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len, > > SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len, > > unsigned long, prot, int, pkey) > > { > > + start = untagged_addr(start); > > return do_mprotect_pkey(start, len, prot, pkey); > > } > > This seems to have taken the approach of going as close as possible to > the syscall boundary and untagging the pointer there. I guess that's > OK, but it does lead to more churn than necessary. For instance, why > not just do the untagging in do_mprotect_pkey()? I think that makes more sense, will do in the next version, thanks! > > I think that's an overall design question. I kinda asked the same thing > about patching call sites vs. VMA lookup functions. Replied in the other thread.