Received: by 10.213.65.68 with SMTP id h4csp1072177imn; Wed, 14 Mar 2018 08:47:31 -0700 (PDT) X-Google-Smtp-Source: AG47ELsCUYr25DgKPlPkO9chI5UD4nZk7Q6w7zbhiPHr6UjXUSUkprNzY02XiLTh50dN0kvlLIYC X-Received: by 2002:a17:902:64cf:: with SMTP id y15-v6mr4590357pli.49.1521042451156; Wed, 14 Mar 2018 08:47:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521042451; cv=none; d=google.com; s=arc-20160816; b=DQQEcLDBcAmQqls48yUXVY43a+g8GBARM+jutiJMB9KxxCDdYXz7vo9dwF8JzATEEQ mjfe4WSAnBs+t4Isr//+F5q9kzXfxoXKg3B98u8Vyg3XhM6rMufq+YbEc2iFe4Auefsu xam8CQeu07tLXUcH3X8AYRMFu3iRU1rUcgGPxlz5yaE3D3xxcQ2NOvzDTulpJhK3wlmG 7P6M0xYV7PGaMUNRwHdq3kGXqWNMUe/AxJWG/py86pdHMt68Qq0ooy9pclORIAcDTNLE CcbY3qWVi2i85GthjXbPmjvqM6S8Q3jqwnnhe730fzEMl5q2TeftmkHDzIPxIPDqvyMq F0aA== 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=+1jg6Bunga62eu1GEOXv1r5xCnkaa6H2fGxtIc3o4jQ=; b=irH7mXOGwq7NUAL+/WPwDjxLRLGcRBtIgsdSPoHa9/U9UltaWmKZ2bTN/jcGWFBo8A C0isAjUCzQU2xCqkey8WNP9GwwWzJNHn5NKlA6BYC/aNazZziz3HX4s8G8M8wnj/rk2P 49OjclUi1XfOa/nUW0adUVk+5SBbbFUfqEbmtsWBLQN7cCTFYfjK/JZbVk632i+d0PvX aJP7rQn13BQLuxhQ8k1Xua8pKAjeX3P0eM+BWkq3hLvF79CW9runTyPwYspaKrSezNEY QpsdAXcOuEg9jBzMM2jS4zxU43XCLTioQlKPwn7g/2vJuu/JC/3nYeLHJOCwFZU6/P4V yR3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FFwzHyEw; 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 1-v6si2184273pln.656.2018.03.14.08.47.14; Wed, 14 Mar 2018 08:47:31 -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=FFwzHyEw; 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 S1752408AbeCNPpY (ORCPT + 99 others); Wed, 14 Mar 2018 11:45:24 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:38094 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752263AbeCNPpW (ORCPT ); Wed, 14 Mar 2018 11:45:22 -0400 Received: by mail-it0-f68.google.com with SMTP id j7-v6so5300382ita.3 for ; Wed, 14 Mar 2018 08:45:22 -0700 (PDT) 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=+1jg6Bunga62eu1GEOXv1r5xCnkaa6H2fGxtIc3o4jQ=; b=FFwzHyEwL+xZWY9qBRtjbm1UjLPYygmqaKhSJMUtsVZr+5Y8HXFyxLodL4X2W6LgLN hbLPS7xdQEGmsvOTYU7/oFmJ9OMRiTmBQFBchSUJhwpNl5eZsyTI4+Owrw/+3j38N/GI 8Jp/RxN8DlJ+NumRnYGh5PBFrFOqdZYpuZzL+vY2QtD9yqVdpxx/pnfzi2SYVYxSx9Rm 20Bm8acDZBXMN7Wp353wm/zy7CX8iZj8dQCiUbx/oSAkvirWBQtawlJ/uOGdNsOoRe4a DqfSiHevM/mz4hATGdZqZege59xEE+dOSPtZuD3advtyvjsdRWUz9+3/mVbRoGj9+wR6 ivWQ== 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=+1jg6Bunga62eu1GEOXv1r5xCnkaa6H2fGxtIc3o4jQ=; b=thpswjjJYwC+jqZH/Z+6h1Z7UwmJIUvgXKQqo1sy8zhcRv8F02zPSuzcKN5/7SvoAr /fwalQ6RV7ynWl6LDQMYVB+OM6Zt5WYshonBnvO+avQMMZN5vqGZuIvU5shdQ1qu2595 Y0fQKo/w4ZeDgYAgiIMJkOPcoJ8+tB4S4YUhyDUhlZHW2OK27ycy8wU1Z36wrOVL+Qkz 77E+OJqrKccTjAhWUxa733Bb6pvODWvLUM7gHkH+ecdq9WBwA3P8adipB5DZRf2tguOg nk3fMdRknTzZnIANHZYIJuE3in33fu+vwX4KWJjqDzZJH65E4/6Xf/DKo5mqyvKcaoOM 7HZQ== X-Gm-Message-State: AElRT7Ey3WuRqnEZNgsJ91Dwn3J3GwB3rEbI8E5OWnnDNcNRh9e/zufl iJgdQYlsVU6TeL73XPf8uhPdHzlmNgdVyu90VWFKzw== X-Received: by 2002:a24:ee8b:: with SMTP id b133-v6mr2645250iti.48.1521042321377; Wed, 14 Mar 2018 08:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.102.68 with HTTP; Wed, 14 Mar 2018 08:45:20 -0700 (PDT) In-Reply-To: References: <20180309155315.4x44sbp3darractt@armageddon.cambridge.arm.com> From: Andrey Konovalov Date: Wed, 14 Mar 2018 16:45:20 +0100 Message-ID: Subject: Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls To: Evgenii Stepanov 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 6:42 PM, Evgenii Stepanov wrote: > On Fri, Mar 9, 2018 at 9:31 AM, Andrey Konovalov wrote: >> On Fri, Mar 9, 2018 at 4:53 PM, Catalin Marinas wrote: >>> 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. Catalin, do you think this is a good reason to have the untagging done in the kernel?