Received: by 10.223.185.111 with SMTP id b44csp578885wrg; Fri, 9 Mar 2018 09:44:20 -0800 (PST) X-Google-Smtp-Source: AG47ELuZUkAm7VgkRq/maN33kf2uSASWID1H0b108ck+kn5qPmU8r4r8YLictyt4oTvAo91sDA4t X-Received: by 10.98.72.204 with SMTP id q73mr31051114pfi.48.1520617460243; Fri, 09 Mar 2018 09:44:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520617460; cv=none; d=google.com; s=arc-20160816; b=nbWicJDCFWFLZpH97WjZ0Vmi1DXFLGuPiBYFpe++81s5aIUWCKRYQWPDeL5G5bWfl4 cd5mFY7GWFDISvsX0reY1rtdWWsynlJSfmeZ8kIkLtUBkRTsADyUrobA7z+jI9Q8Tsnm iQCrumAKCpQs6esCDosGm8SGOuj9IAdtri42rftaSbh2P1bqYEtKh2i7h5g46ygH0qcg V0gr6LsEaHYADwlNT5pJZyWfcY7M3QAjDg3uXmjxAOfIPbcuJJUsB4qHV/GzMydf6M5w tlm4+S+cPAEtrG5Pn7CHacMToiMFQZbqvVQ9yqvYGGUgplA9K7+UH/JKMv98itru8sOw 0FRA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=uSHkJK93yMDFGgmf0cv2VAo7nf8zwaAi+49dr911XZs=; b=OpzqmVw9cX7EEuNIORFBsB50KCHB35EZ4dQOJ6KSJcVxLj3X8qSnTjpvTKwTG84gVN c8U2aWqBJc1w5wDypCy6m50sx1YQmhNQRPgKz4xCnEsURXq1DIl2EBD1ZOXTPhU2iRij G1sU+1AuyGNx7yn6OVqztjRiD9Lk5SWoADZq5zVT6MbgOaJUbq6YwnukCnVJ9nSy2Aj/ gO5OgEQba6VDVT2Oq+dY7wkH7xi4IIZcX1Vvt4pkrGfcSdjLuX5gzZXqGw8fBSM5TFFe S/K3LEM3kweK79d4E6UVwBGLwI867vxLf2oHxqoWk6VkTlZf9X463iFSACdTr9sDTG7Z /oQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=fG6030aq; 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 t134si1011995pgc.664.2018.03.09.09.44.05; Fri, 09 Mar 2018 09:44:20 -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=fG6030aq; 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 S932384AbeCIRmd (ORCPT + 99 others); Fri, 9 Mar 2018 12:42:33 -0500 Received: from mail-yw0-f194.google.com ([209.85.161.194]:39063 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932288AbeCIRmb (ORCPT ); Fri, 9 Mar 2018 12:42:31 -0500 Received: by mail-yw0-f194.google.com with SMTP id l24so1383709ywk.6 for ; Fri, 09 Mar 2018 09:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uSHkJK93yMDFGgmf0cv2VAo7nf8zwaAi+49dr911XZs=; b=fG6030aqL4iQwony+ifzcvgTWFvlKYVcCiaAR2Ivdk3FvQ9K29IkYUjK1PgA5eeTCl dEQcyHxobwTgCgQE1iq3ng+iM0bcYG1/ayc+QdFvDIc+VCoRAEZZict5YX9CA2gBNIqo Z8HYNNCoz4D3EQJP5+9XKyCOKm5hZ++WXm6MW9lzHDMz2biiPvk7R3qMBUDXYe+wOCkR Ae0/Up1t9TUymCwpzpaSTVUd85tL/l33uRt9/HYd+JOjj5vhqNFXkD3AIjRUeqzBX2G0 FChHgqCPy/Pgn7W8J78Wk2C1fmurwB3aWWwaJSyCfjJLtN4XcE38v45TP+jnrl1to15A T0ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uSHkJK93yMDFGgmf0cv2VAo7nf8zwaAi+49dr911XZs=; b=W5aTEZlxqzlgLKV5gzt3YzbADnaUtgL+GAi7vYFxUAJJH7YTffpgLWmG0NlhBCYyE1 DCzTXTrUZJiw5BhSIutNQFdt+vP4mB8+YqXvi5HSu/CZN/mALPZriaebY+H+f4Kwpn73 XPtLv7StgLEU4hNqojRCjwUAS2nxAlh9K0lNy4a2nKp7QAOvoY45kuyiQCuY5uCojSuP hr21GRrvAqoZX9L/snHivgntJaARX8CNKPwq3gly1XcMDMxj+1l9i3tATtN4rg8t8L+z /tWPNbPOv95YjwiQQtQoN/SCHKi7Wr8slEOAPSWpvNHO1sLYNI9AXzCQv40HuCFlCCiR 2ymw== X-Gm-Message-State: AElRT7E4TG1tudwdgUJOWp2/0fL6v/oW6MoVujGXyCAloKH9VO1FiQRA 6MNGhZ47uDAkYMLD16LCdPtGdQ53MQTxFa2pbTNkOBpD X-Received: by 2002:a25:4003:: with SMTP id n3-v6mr2112774yba.390.1520617350401; Fri, 09 Mar 2018 09:42:30 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b9c4:0:0:0:0:0 with HTTP; Fri, 9 Mar 2018 09:42:29 -0800 (PST) In-Reply-To: References: <20180309155315.4x44sbp3darractt@armageddon.cambridge.arm.com> From: Evgenii Stepanov Date: Fri, 9 Mar 2018 09:42:29 -0800 Message-ID: Subject: Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls To: Andrey Konovalov Cc: Catalin Marinas , Will Deacon , Mark Rutland , Robin Murphy , Linux ARM , LKML , Arnd Bergmann , linux-arch@vger.kernel.org, Dmitry Vyukov , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan 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 9, 2018 at 9:31 AM, Andrey Konovalov wrote: > On Fri, Mar 9, 2018 at 4:53 PM, Catalin Marinas wrote: >> On Fri, Mar 09, 2018 at 03:02:01PM +0100, Andrey Konovalov wrote: >>> Memory subsystem syscalls accept user addresses as arguments, but don't use >>> copy_from_user and other similar functions, so we need to handle this case >>> separately. >>> >>> Untag user pointers passed to madvise, mbind, get_mempolicy, mincore, >>> mlock, mlock2, brk, mmap_pgoff, old_mmap, munmap, remap_file_pages, >>> mprotect, pkey_mprotect, mremap and msync. >>> >>> Signed-off-by: Andrey Konovalov >> >> Please keep the cc list small (maybe linux-arch, linux-arm-kernel) as >> I'm sure some lists would consider this spam. > > OK. > >> >>> mm/madvise.c | 2 ++ >>> mm/mempolicy.c | 6 ++++++ >>> mm/mincore.c | 2 ++ >>> mm/mlock.c | 5 +++++ >>> mm/mmap.c | 9 +++++++++ >>> mm/mprotect.c | 2 ++ >>> mm/mremap.c | 2 ++ >>> mm/msync.c | 3 +++ >> >> I'm not yet convinced these functions need to allow tagged pointers. >> They are not doing memory accesses but rather dealing with the memory >> range, hence an untagged pointer is better suited. There is probably a >> reason why the "start" argument is "unsigned long" vs "void __user *" >> (in the kernel, not the man page). > > So that would make the user to untag pointers before passing to these syscalls. > > Evgeniy, would that be possible to untag pointers in HWASan before > using memory subsystem syscalls? Is there a reason for untagging them > in the kernel? Generally, no. It's possible to intercept a libc call using symbol interposition, but I don't know how to rewrite arguments of a raw system call other than through ptrace, and that creates more problems than it solves. AFAIU, it's valid for a program to pass an address obtained from malloc or, better, posix_memalign to an mm syscall like mprotect(). These arguments are pointers from the userspace point of view.