Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp514719imm; Thu, 30 Aug 2018 04:49:42 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaazsrsJ2gFh6rLjNowX7u2PLydf+MecgxA6c8vN7Pw6gFvqWEA+AXFpdS3je47a5YojHeA X-Received: by 2002:a63:5a13:: with SMTP id o19-v6mr9330237pgb.75.1535629782737; Thu, 30 Aug 2018 04:49:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535629782; cv=none; d=google.com; s=arc-20160816; b=j4tObbSHJWQiaPHBi9GdkY0Z5dlVB2zbkaeG0eAemfjhrVP6ZdiCFAf07XjfcIGm7p K3RC+4F3WhJMH/rABYS7pGM3W6jy+o/eAit5SU2fBvreAvh+ssw61dLW+BkDYzcXX/k2 7fk6wNzdMN7JYbQDjeAztWUmhOP91GIB23RD1liuz6G1bMZ1fMXWFteG4iLDbDtcAgp6 rPjA3BCydI/zW5WNRrF0cZ9/WB5djY0nNXdZqVzyl5Y5uHTMnsZMiTSMdwhgSksFrjf5 TuKUhX1rp/KfwbyGiw7Ojzcllps/WT5XRWnIy9P1lDA6GTDSb/EF5D1Wa+ZNoEun4oeR yYnw== 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=E/yy+1Y+flgnyyLy3ZISq6eXjOepMPD+ZhZMDllZ/Sg=; b=LNBSNNiO76izZpD+uwycMFiK8RlIS4mKQa7nMxW1GxejVsISGstTlWr/5XhgvhO4R/ 1krgbh2rbd8GK+ikEZ9y2xjzIGhPbV2IWoJPQAsZCDsm4Lm7xPc0h7l3hPJnrwyaI787 iB+QpC9tyUvpSGM+8f+xspGajAqYbDrtcyoGRgyzb3pFqiIbndoPsBjKZBA02YBRZG1v PAYjkR+GixFyB6ue4eMKHulUzVY0UsYZcbCuoF/wvjTU9UsIz+/vS58Gt2HzFWdRcZ+u hZ/yx4GJUAWl3sFfJmWyx16NEKcrfJJGz7Ke8Pym7sqwhGjyen3lRx3/rERKDXOsw8cu 6+Eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IGMxAMkz; 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 i5-v6si6199816pgg.84.2018.08.30.04.49.28; Thu, 30 Aug 2018 04:49:42 -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=IGMxAMkz; 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 S1728441AbeH3PuC (ORCPT + 99 others); Thu, 30 Aug 2018 11:50:02 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:33696 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728336AbeH3PuB (ORCPT ); Thu, 30 Aug 2018 11:50:01 -0400 Received: by mail-it0-f67.google.com with SMTP id j198-v6so1933345ita.0 for ; Thu, 30 Aug 2018 04:48:16 -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=E/yy+1Y+flgnyyLy3ZISq6eXjOepMPD+ZhZMDllZ/Sg=; b=IGMxAMkzDZc7wE3meawP5g8+2N0zKdm/Hdd0FNS+IVWYPRyE4N7QGNOnnD7l5kTt6d i4ciPgLBXS62L68DUg4K0L3xzHoErViwcZWzNeFmoaMyiBouPvUSCMoaaR2nR9hihx/T 501ded91Fgo6lAoVHm1QSVf4j5uYPiPLYvJn71byzMVDubeNpS1ImnQA3F757rRzd8BM EUJuK1JLxj1xNDIAXyuxpqU4+J5KOInE4vgYuGg/7jdZGXLx6Gy7ivMOS1+t5WbWTzCe FAEloGqHGmZjT5l8L3kpyDKQ1lLaVFbiNtW3jOZJqSjIorW8g17ZCaZ+Wc9k9vfSgKKP ikFw== 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=E/yy+1Y+flgnyyLy3ZISq6eXjOepMPD+ZhZMDllZ/Sg=; b=g72GllFyBeZ6fv09Q9JBg7knPCVi+8zMRj0QLq/X7ktYEJxc1O6XWfgKEhUb/8Rco6 dQJwwIQiJKmzxu8tM6pivq9oI4G6PWW9xQL/XTHc65irGNxHchW7IkIuPnmKzvTV/Ps9 qaQ3y0L3yvQ4eKl5wMz3EFm8c5lj6Xirgm1jVzJkY5gbyvhufom5PZ8ZNmXg61QDnIB0 UQQkfP+opS+nyLXdB+9jIn4G4di43B28L1xV3YlU4MsxRPBQ3LP+9ZhagMBc0qyl2vQg V3dRuhfLtimrlHPGWZRjGnjSGeUvXDtKEi/jIxlIKT5jXLT+RBMvOML8Gdzi2oC91zs5 rljw== X-Gm-Message-State: APzg51BwNb8NH/kJx0l3GfPA3GyqNTUEN7LMYzK0EBOWj7lr5eCVtyy6 u0hj7I5N7Y9VHThaYQnyhRp/12FcVNi48asfG5TX6w== X-Received: by 2002:a02:9962:: with SMTP id d31-v6mr8940993jak.1.1535629696009; Thu, 30 Aug 2018 04:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:882:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 04:48:15 -0700 (PDT) In-Reply-To: References: From: Andrey Konovalov Date: Thu, 30 Aug 2018 13:48:15 +0200 Message-ID: Subject: Re: [PATCH v6 00/11] arm64: untag user pointers passed to the kernel To: Catalin Marinas Cc: Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Chintan Pandya , Will Deacon , Mark Rutland , Robin Murphy , Al Viro , Andrey Konovalov , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Linux ARM , linux-doc@vger.kernel.org, Linux Memory Management List , linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, LKML 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 Thu, Aug 30, 2018 at 1:41 PM, Andrey Konovalov wrote: > arm64 has a feature called Top Byte Ignore, which allows to embed pointer > tags into the top byte of each pointer. Userspace programs (such as > HWASan, a memory debugging tool [1]) might use this feature and pass > tagged user pointers to the kernel through syscalls or other interfaces. > > This patch makes a few of the kernel interfaces accept tagged user > pointers. The kernel is already able to handle user faults with tagged > pointers and has the untagged_addr macro, which this patchset reuses. > > Thanks! > > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > Changes in v6: > - Added annotations for user pointer casts found by sparse. Hi Catalin, I've added annotations for the user pointer casts pointed by the new sparse flag -Wcast-from-as as you asked. I've used __force casts instead of adding specialized macros. There are also non annotated casts for other pointer types (iomem, rcu) which are detected with the new flag, should I annotate those as well? I'm not sure though what value would that bring though, as there are ~3000 various sparse warnings produced with the default flags anyway. WDYT? Thanks! [1] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292