Received: by 10.223.185.111 with SMTP id b44csp568105wrg; Fri, 9 Mar 2018 09:32:51 -0800 (PST) X-Google-Smtp-Source: AG47ELscvzqHOWykpR8tmDpowZLrFKKWOogXHb6BrZ12qBTuP6pyFO5zNPXxxve8BWuCOaVo5Zcu X-Received: by 2002:a17:902:7445:: with SMTP id e5-v6mr28363576plt.204.1520616771582; Fri, 09 Mar 2018 09:32:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520616771; cv=none; d=google.com; s=arc-20160816; b=TDoIQiNn2GnQA2fUDAopsbLTI8vwouYOcrgz0cZpiEBgu1vbdTZgsSkvnHbAvrD+iD Fw0ZSBiE3Q2OLdLNJwUGyyEliZ7CNOa3zyMILHoLY48pvb9v6lXaQDWARxZpMvkWVgVk cGm66bKfc0YEbvx4ORF/kUvROoZLBa2GCjnXXsO6WXU0lDRGRicSk+rTZzHdbjGjOhs5 Tbq34NWZlGdeznJJCm/kWc4p0uS/atAPlnn1/tDC48pl6VmGw9V1SFoRUOA4wC+J7tRU LACtwmwQPq2DUv4jlT4QyLIDdm/ijbWLiDJ3utN78n33nf2etEQ1P1YKnt7HZnqM6L+8 M7IA== 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=nzxDFs91zbTAQo3T+oILRkhOpR3Ou7/qGx9s3jO+ol8=; b=Fe96+4brH7DFTtA03Z9Eu6xBZ88nr+B35NKTramhmkpcgBP0eOpDzMoJm+5j1vB7aq 6bFfC3wPO1IBwesK3Vo47hl0Ut187H/BCc7CSbiEk13qcxuarb05BTAttTTjJh2QTri8 MtWA3+q0389IXEqxCxZS0YtVnESwyyUAewaiOzZcAgkQRZ9SoyN8A8Eq+8YDk6QeA8TF KqgeE2R5IuYfrenJYptignEj+eR+njrF/mGWLi0jyn9+sjUQScK6lpKz4+VIlAwqhskR N/gV4gfDW5NMKzU55TW14VN1QHx0srSVMbQX3VQ4HIDvZIfwgs/2/dkcbRW3xzh8LdGZ +1HA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ab9VEJYO; 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 d5si1196215pfl.224.2018.03.09.09.32.36; Fri, 09 Mar 2018 09:32:51 -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=ab9VEJYO; 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 S932288AbeCIRbj (ORCPT + 99 others); Fri, 9 Mar 2018 12:31:39 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:42860 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751192AbeCIRbi (ORCPT ); Fri, 9 Mar 2018 12:31:38 -0500 Received: by mail-io0-f194.google.com with SMTP id u84so4326549iod.9 for ; Fri, 09 Mar 2018 09:31:38 -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=nzxDFs91zbTAQo3T+oILRkhOpR3Ou7/qGx9s3jO+ol8=; b=ab9VEJYOTNl6L0SNQsjGS8+uKc4+cRECNqM4kNfKTmA1BwDajwQNKT8LLjO4W9P067 Ud+Sz6oQSfTqRbTc0QvqR7fiG2F94xvDRzlIX+LVMGOzJN8M9WH6U/0kt8BNXvnVlPlO dNPUt80b9mgLBQs+/sg0oLO17nTFAd+6U8b+0GzHGij9BJuzXy5tKX05X4WNlUo0A2CZ /c5ySGhstwDjcdHVuS8raXzUwgoQ6TA3lwuGJ0JaIs3YQz0ezW47u6UVLA97QCttwRFx 1iHwPVNX/tYJLYY3k2LLLpU8bx6PLHhudExysLFXm1nHB3APXc4nS8a7QF3LCOqxdWo1 iz4Q== 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=nzxDFs91zbTAQo3T+oILRkhOpR3Ou7/qGx9s3jO+ol8=; b=cr5ICrH3Rdclyt7K1Y9rvOU63INVDZh3SpPiRZ6XQokIfQbFVgJyGvsdImERZhP0ir 9HQrBFhNWwtbDv3WOPAdQHb+GA9EEn4BEaTqiku7fojA/BYsymXdX9be66fQYaBYMRXT I7yJDu6J4F0QeTp5ACVWTQ4Y6psbWuSiwzKD6zc+FDLNtESqJTB3U3kThGEK8y6HGxHl Nz8SadEzf0dJh1uNoGAn7hzKfX00hX5pOXRkvvSm63XZhd6rIQVnAtIomDRGvaOH8RKz LoY8mXQq8EVqnuQBstc5R4TIiRIW4G4kLp/fnKa/uCNh+OKskMONWKf3BY/trP4HRhnR USpQ== X-Gm-Message-State: AElRT7GjyYfzc4M8QNc2R3C5Sl2ZXbz/WBYIsayMcEocmIJ1ZIOPEv0c XbeWBw1yHlnVZTIo1hfte7rYRG5rfSWnoE8PjKEhOnLkGDU= X-Received: by 10.107.170.158 with SMTP id g30mr17665212ioj.31.1520616696843; Fri, 09 Mar 2018 09:31:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.102.68 with HTTP; Fri, 9 Mar 2018 09:31:36 -0800 (PST) In-Reply-To: <20180309155315.4x44sbp3darractt@armageddon.cambridge.arm.com> References: <20180309155315.4x44sbp3darractt@armageddon.cambridge.arm.com> From: Andrey Konovalov Date: Fri, 9 Mar 2018 18:31:36 +0100 Message-ID: Subject: Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls To: Catalin Marinas , Evgeniy Stepanov Cc: 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 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? > > -- > Catalin