From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_MED,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3382C43142 for ; Thu, 2 Aug 2018 15:00:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C9AC2151B for ; Thu, 2 Aug 2018 15:00:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rjloKgKx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C9AC2151B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732567AbeHBQwA (ORCPT ); Thu, 2 Aug 2018 12:52:00 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:36088 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732525AbeHBQwA (ORCPT ); Thu, 2 Aug 2018 12:52:00 -0400 Received: by mail-it0-f67.google.com with SMTP id p81-v6so3696782itp.1 for ; Thu, 02 Aug 2018 08:00:26 -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=+6+ZVXBDS+MdjbGlZis5tLN4pZnRxLkrlq2TxOkZY64=; b=rjloKgKxvf6gtZAosHUG/a2cex4b8sIGoe/SPjdisBLSa/1LTwU8Pp7PEL9DZF12nm 5HsF5EEs4v+bGTtkTHd5mQLu81g9jhdIG9oKcqsYZQUtSMVeWYSFAieEeRF23qm1OFN8 QRE3VyiS596B35XT31EV27ODwX/ymugFpHYzQAAidCuYSDnlKa4CHRhcOy71BTE3dGoO pvbvt5NBAnJVRkPqkB40LvmSv5UutT7QSPREXPL2V9jR9vOZyTjVNuaNGiWj0DFFcFRw lBHq4k/9EmEIUgmaJI5WjPuLFDpZFLKUuC0YBjFtTpqcxcZVS7ELm21h/GsEIOoyrLm7 2iPg== 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=+6+ZVXBDS+MdjbGlZis5tLN4pZnRxLkrlq2TxOkZY64=; b=PKb9DXWCheH3QKp9VGyVxsif0t336LdAhGdjyDt//IfsMcyE4JOmjm+PRcFPZ8mc8j kRsGbAwhdQiK5lB++FpnXQELCmKejWCPJZIGWA2wP/8bwMzX7VWmMzaJfTrJko95CX0M ++24glVqOaISHabMkbDdbvvf7AFHNK4zJDNy83bdYFUnqfkVKNDD/pzWJ4oxZep4g7Sw evDtjHmcbIMrr/at88tfm/jKVutlfI7EH5xgchfNfXLj3jh0ttzF7Ok548VatKBvCc47 0U5XVXLzMZHYX5LT8aAyxmxyR/TIGVwH+Hqsx3ndk96xdedpe1xdTcabFxvhdU6nujuG ib+g== X-Gm-Message-State: AOUpUlFrjqQIVRyp6T05gvNdjqrdrx4hQL+FAwqluSai+erx8K8NnevQ hpWaMmlejYNVF4kzn9WzjfNZ4SpH/O58Wl4feUcZYA== X-Google-Smtp-Source: AAOMgpfVwDqyoEOewzkNDe3n/znU8SXglGI/4RhK+n/piEqUOJDiavwKUcdbki2OcbxRalg/vULNN+1Gwk4Hswp9IGU= X-Received: by 2002:a02:ac8f:: with SMTP id x15-v6mr2815342jan.132.1533222025880; Thu, 02 Aug 2018 08:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:918c:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 08:00:25 -0700 (PDT) In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> From: Andrey Konovalov Date: Thu, 2 Aug 2018 17:00:25 +0200 Message-ID: Subject: Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel To: Catalin Marinas Cc: Mark Rutland , Kate Stewart , linux-doc@vger.kernel.org, Will Deacon , Kostya Serebryany , linux-kselftest@vger.kernel.org, Chintan Pandya , Shuah Khan , Ingo Molnar , linux-arch@vger.kernel.org, Jacob Bramley , Dmitry Vyukov , Evgeniy Stepanov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Al Viro , Linux ARM , Linux Memory Management List , Greg Kroah-Hartman , LKML , Lee Smith , Andrew Morton , Robin Murphy , "Kirill A . Shutemov" 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 Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 720F87D581 for ; Thu, 2 Aug 2018 15:00:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732527AbeHBQwA (ORCPT ); Thu, 2 Aug 2018 12:52:00 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:39563 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732202AbeHBQv7 (ORCPT ); Thu, 2 Aug 2018 12:51:59 -0400 Received: by mail-it0-f68.google.com with SMTP id g141-v6so3655750ita.4 for ; Thu, 02 Aug 2018 08:00:26 -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=+6+ZVXBDS+MdjbGlZis5tLN4pZnRxLkrlq2TxOkZY64=; b=rjloKgKxvf6gtZAosHUG/a2cex4b8sIGoe/SPjdisBLSa/1LTwU8Pp7PEL9DZF12nm 5HsF5EEs4v+bGTtkTHd5mQLu81g9jhdIG9oKcqsYZQUtSMVeWYSFAieEeRF23qm1OFN8 QRE3VyiS596B35XT31EV27ODwX/ymugFpHYzQAAidCuYSDnlKa4CHRhcOy71BTE3dGoO pvbvt5NBAnJVRkPqkB40LvmSv5UutT7QSPREXPL2V9jR9vOZyTjVNuaNGiWj0DFFcFRw lBHq4k/9EmEIUgmaJI5WjPuLFDpZFLKUuC0YBjFtTpqcxcZVS7ELm21h/GsEIOoyrLm7 2iPg== 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=+6+ZVXBDS+MdjbGlZis5tLN4pZnRxLkrlq2TxOkZY64=; b=Oc6seslqcNj3OJV2lMI0eWkh8IBcvVg4TjnbSvD0anktycrwRzVOKicWYryhnmHcCs K27hibieHzewNwOl7/HILbBtAbqceGMfoMJOhRs5McBpYxBrbK5i4p5MU+91mmcTl8U0 VlcZRp4Pv92KWhHra3TrZ4n6w86ANGi15VlbmLKMvj9WVedSm5dA+LKvrMDKfdOU+Ucf fD5xSGDxZksiDCHTTtiRaBMTyxR7QCcJem1dp2p+jhiQ9OjIKlf1AYapWhV6B64vF+fp Ne/krIJjbkb2ZhVWSBUFfo8l4TAzwbm9Xl10VAtPPfHvALVtPrYtV+qeI0WXahC3sXQT NYxA== X-Gm-Message-State: AOUpUlHuSw4evHLy8JJsf4GfGlxQPuKoBgUXpJezzitf7kaTXUBtHRW1 uAjjIdP2Pu7wW2K1+tXvSzGT3cQeDhJ1kFwUQMC/9A== X-Google-Smtp-Source: AAOMgpfVwDqyoEOewzkNDe3n/znU8SXglGI/4RhK+n/piEqUOJDiavwKUcdbki2OcbxRalg/vULNN+1Gwk4Hswp9IGU= X-Received: by 2002:a02:ac8f:: with SMTP id x15-v6mr2815342jan.132.1533222025880; Thu, 02 Aug 2018 08:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:918c:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 08:00:25 -0700 (PDT) In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> From: Andrey Konovalov Date: Thu, 2 Aug 2018 17:00:25 +0200 Message-ID: Subject: Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel To: Catalin Marinas Cc: Mark Rutland , Kate Stewart , linux-doc@vger.kernel.org, Will Deacon , Kostya Serebryany , linux-kselftest@vger.kernel.org, Chintan Pandya , Shuah Khan , Ingo Molnar , linux-arch@vger.kernel.org, Jacob Bramley , Dmitry Vyukov , Evgeniy Stepanov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Al Viro , Linux ARM , Linux Memory Management List , Greg Kroah-Hartman , LKML , Lee Smith , Andrew Morton , Robin Murphy , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreyknvl at google.com (Andrey Konovalov) Date: Thu, 2 Aug 2018 17:00:25 +0200 Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> Message-ID: On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately? -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreyknvl@google.com (Andrey Konovalov) Date: Thu, 2 Aug 2018 17:00:25 +0200 Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> Message-ID: Content-Type: text/plain; charset="UTF-8" Message-ID: <20180802150025.bV2F1kBhvSgWvCWKG4lzgrr0DwVscEwRp20tLuKTWr0@z> On Wed, Aug 1, 2018@7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately? -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Konovalov Subject: Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Thu, 2 Aug 2018 17:00:25 +0200 Message-ID: References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Catalin Marinas Cc: Mark Rutland , Kate Stewart , linux-doc@vger.kernel.org, Will Deacon , Kostya Serebryany , linux-kselftest@vger.kernel.org, Chintan Pandya , Shuah Khan , Ingo Molnar , linux-arch@vger.kernel.org, Jacob Bramley , Dmitry Vyukov , Evgeniy Stepanov , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Al Viro , Linux ARM , Linux Memory Management List , Greg Kroah-Hartman List-Id: linux-arch.vger.kernel.org On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately? From mboxrd@z Thu Jan 1 00:00:00 1970 From: andreyknvl@google.com (Andrey Konovalov) Date: Thu, 2 Aug 2018 17:00:25 +0200 Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel In-Reply-To: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas wrote: > On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: >> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov wrote: >> So the checker reports ~100 different places where a __user pointer >> being casted. I've looked through them and found 3 places where we >> need to add untagging. Source code lines below come from 4.18-rc2+ >> (6f0d349d). > [...] >> I'll add the 3 patches with fixes to v5 of this patchset. > > Thanks for investigating. You can fix those three places in your code OK, will do. > but I was rather looking for a way to check such casting in the future > for newly added code. While for the khwasan we can assume it's a debug > option, the tagged user pointers are ABI and we need to keep it stable. > > We could we actually add some macros for explicit conversion between > __user ptr and long and silence the warning there (I guess this would > work better for sparse). We can then detect new ptr to long casts as > they appear. I just hope that's not too intrusive. > > (I haven't tried the sparse patch yet, hopefully sometime this week) Haven't look at that sparse patch yet myself, but sounds doable. Should these macros go into this patchset or should they go separately?