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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 4AE58C4707F for ; Fri, 28 May 2021 01:05:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E7012613C9 for ; Fri, 28 May 2021 01:05:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7012613C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8524C8E0002; Thu, 27 May 2021 21:05:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 800B06B0071; Thu, 27 May 2021 21:05:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62CFD8E0002; Thu, 27 May 2021 21:05:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 2C0196B0070 for ; Thu, 27 May 2021 21:05:54 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B9D03180385D0 for ; Fri, 28 May 2021 01:05:53 +0000 (UTC) X-FDA: 78188847786.03.3173F77 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf24.hostedemail.com (Postfix) with ESMTP id 59ED5A0009DC for ; Fri, 28 May 2021 01:05:45 +0000 (UTC) Received: by mail-io1-f42.google.com with SMTP id d25so2523882ioe.1 for ; Thu, 27 May 2021 18:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+nnv7ABDUKYCohmfTaJwqMRY72SNRc11cD++gX8Mf+o=; b=QjD20J9cTQAkKuYElTbqgF7GkiYzqG6QNT60R9EkhkCcKrfXE55JfGWFjCQofsg0K+ q3co/1AhZn27xTbRvada6JaKyEltJO5IKM+VwG8Xw1y+qG2LcnpZOfLj++4wuH/V20a8 NAOX9FPEp2vRZw9P3GUAUzy6tMFBVBsH3wwOPFHiFtj57ieBm4yseCESh3dw3E6msOoN rXuDZFyKbjTa0XKbICFYJl/gH50aH+UaPGlBGgmx/lMvGLOvU4erS9/FOpx1MpYyWGI0 OyizESTnf9DJzAXzv91m0boG+MRfph7Lg0jdkdMRwZvSjdlxFN5XPH1B6tXIGRsaBRZ1 bNaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+nnv7ABDUKYCohmfTaJwqMRY72SNRc11cD++gX8Mf+o=; b=sB3kSaOHAQnNNj8gS6sYjqtT5JvVznrbGKb1nrbX1ekWY1Bbd5LujitQpXNw7xYd6P QZ6TvEb7Ofw+rQxdgIYY34/nIoHhbUbvcSGsRVSM7SC5mBWTD5JLbYPqL8Qu5Bxxo2yl 2pWt1IP+nzBxnvUcFZi3VDq64DQdZkEnzNcNTH/Ae5BvnE0ZxJkGJ8aheWwEYATKAPZl 8gOseD4rCnWPJ51XdI9lWxctL4AJrnanFf4nXygNwNiTXeEC2mpVF76yqHP1KV7ZpxFo XpJFSUVWezFwhXb0wYFr2y8FbxCEA7atuNqhwafCr5i1MrX2nlW/ugwRlzu3sN+pKuZE /ssw== X-Gm-Message-State: AOAM531RR5wvxHbwDNNw4NiEX9OKJJUL0Kcbh+K2YY0uPxrW8yA75cmw mjHJWRry7FGuDGFynFenyRJgb2Arv+JxafWuTF3Xfg== X-Google-Smtp-Source: ABdhPJyE231MwA0PwTEiZMRLIPQSYzlYYMaMHyX7dns85rHLTln6OT9sFx5kxr480LEIjGUDCepuPN1o8M5KkOFxeXo= X-Received: by 2002:a05:6638:13cc:: with SMTP id i12mr6054871jaj.20.1622163952765; Thu, 27 May 2021 18:05:52 -0700 (PDT) MIME-Version: 1.0 References: <31b6c0c44cb385667287c826528ad422c6433091.1620849613.git.pcc@google.com> In-Reply-To: From: Peter Collingbourne Date: Thu, 27 May 2021 18:05:41 -0700 Message-ID: Subject: Re: [PATCH v3 3/3] kasan: allow freed user page poisoning to be disabled with HW tags To: Jann Horn Cc: Andrey Konovalov , Alexander Potapenko , Catalin Marinas , Vincenzo Frascino , Andrew Morton , Evgenii Stepanov , Linux Memory Management List , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 59ED5A0009DC Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=QjD20J9c; spf=pass (imf24.hostedemail.com: domain of pcc@google.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: p638gbrjt8s919pmf11tqgw5k17dhmkr X-HE-Tag: 1622163945-950898 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 26, 2021 at 3:45 AM Jann Horn wrote: > > On Wed, May 26, 2021 at 12:07 AM Andrey Konovalov wrote: > > On Wed, May 12, 2021 at 11:09 PM Peter Collingbourne wrote: > > > Poisoning freed pages protects against kernel use-after-free. The > > > likelihood of such a bug involving kernel pages is significantly higher > > > than that for user pages. At the same time, poisoning freed pages can > > > impose a significant performance cost, which cannot always be justified > > > for user pages given the lower probability of finding a bug. Therefore, > > > make it possible to configure the kernel to disable freed user page > > > poisoning when using HW tags via the new kasan.skip_user_poison_on_free > > > command line option. > > > > So the potential scenario that would be undetectable with > > kasan.skip_user_poison_on_free enabled is: 1) kernel allocates a user > > page and maps it for userspace, 2) the page gets freed in the kernel, > > 3) kernel accesses the page leading to a use-after-free. Is this > > correct? Yes, that's correct. > > If bugs involving use-after-free accesses on user pages is something > > that is extremely rare, perhaps we could just change the default and > > avoid adding a command line switch. > > > > Jann, maybe you have an idea of how common something like this is or > > have other inputs? > > GFP_USER is kind of a squishy concept, and if you grep around for it > in the kernel tree, you can see it being used for all kinds of things > - including SKBs in some weird ISDN driver, various types of BPF > allocations, and so on. It's probably the wrong flag to hook if you > want something that means "these pages will mostly be accessed from > userspace". > > My guess is that what pcc@ is actually interested in are probably > mainly anonymous pages, and to a lesser degree also page cache pages? > Those use the more specific GFP_HIGHUSER_MOVABLE (which indicates that > the kernel will usually not be holding any direct pointers to the page > outside of rmap/pagecache logic, and that any kernel access to the > pages will be using the kmap API). > > It's probably safe to assume that the majority of kernel bugs won't > directly involve GFP_HIGHUSER_MOVABLE memory - that's probably mostly > only going to happen if there are bugs in code that grabs pages with > get_user_pages* and then kmap()s them, or if there's something broken > in the pipe logic, or maybe an OOB issue in filesystem parsing code > (?), or something like that. This makes sense to me. The pages that I'm most interested in getting this treatment are indeed the anonymous and, to a lesser extent, pagecache pages. The GFP_HIGHUSER_MOVABLE restrictions to me imply a lack of direct kernel access more strongly than GFP_USER, as you point out. Therefore I agree with Andrey that we probably don't need a switch for this and can just change the behavior for GFP_HIGHUSER_MOVABLE. I've done so in v4, although this required a preparatory patch to merge __alloc_zeroed_user_highpage() and alloc_zeroed_user_highpage_movable() so that we actually use the GFP_HIGHUSER_MOVABLE constant for anonymous pages. > Peter, is the plan to have this poisoning disabled in production? Is > there an estimate on slow this is? Yes, that is the plan. I don't think I'm at liberty to provide exact numbers, but given that the previous patches mean that at allocation time we only touch pages once whether or not KASAN is enabled, the most significant remaining KASAN-associated source of overhead for user pages is the deallocation time overhead that I'm eliminating in this patch. Peter 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 96A7AC4707F for ; Fri, 28 May 2021 01:22:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 511B96135C for ; Fri, 28 May 2021 01:22:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 511B96135C 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-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bU4b660Q3B4aqwgLioBcVX1uVmXgBIWGfKAi+t4r26w=; b=TQuuJ9xySeLVFX Qvx/w62GI3eiSugWsk5txooTZOZWDxPUfvlzzGkz8MXA0crJgK5EJ26bU7rg6pr2LjsONV/k0EKk2 Q9246qLo/nJ/9AeMIQqGUSwJzneEB+jMXxCLq19XnZT5MTGL9/xx7I2Uyl8iBc0pSlO0V5y896mC5 +8MVWcg5a53W/aXsmoAf2O5oQgfQYfUc6rCcJsorHOAPkyis3/7PeQzHEJnDMqV9+f7jYAR6IEuEe buTqtBGKlxUp8rLgc5ogUS7hYAv3RCHkI+nlMik3jK/cBLwWc+3132W/lQ1Bo7NJXCXKrADiyaEtd V6XVI2/af6lmqFg8hGVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmR9F-00At5B-9o; Fri, 28 May 2021 01:18:51 +0000 Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmQwk-00AoEq-0Z for linux-arm-kernel@lists.infradead.org; Fri, 28 May 2021 01:05:55 +0000 Received: by mail-io1-xd2e.google.com with SMTP id k22so2491445ioa.9 for ; Thu, 27 May 2021 18:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+nnv7ABDUKYCohmfTaJwqMRY72SNRc11cD++gX8Mf+o=; b=QjD20J9cTQAkKuYElTbqgF7GkiYzqG6QNT60R9EkhkCcKrfXE55JfGWFjCQofsg0K+ q3co/1AhZn27xTbRvada6JaKyEltJO5IKM+VwG8Xw1y+qG2LcnpZOfLj++4wuH/V20a8 NAOX9FPEp2vRZw9P3GUAUzy6tMFBVBsH3wwOPFHiFtj57ieBm4yseCESh3dw3E6msOoN rXuDZFyKbjTa0XKbICFYJl/gH50aH+UaPGlBGgmx/lMvGLOvU4erS9/FOpx1MpYyWGI0 OyizESTnf9DJzAXzv91m0boG+MRfph7Lg0jdkdMRwZvSjdlxFN5XPH1B6tXIGRsaBRZ1 bNaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+nnv7ABDUKYCohmfTaJwqMRY72SNRc11cD++gX8Mf+o=; b=ZAMrG8sV0rY8XCw2YXdMq0omL+UXFvn8Rt07sddCZrLcGmsRUYk8WCuO4UDzvjVXRe 1DqOi966zhdv538luZ3imzYcyth4IyMmdikrF3t0NpyE8jqzUVVZp5PbCYDUEcPHYi3y qHAobuEDTM0CexWtIW0qEOSRDRDW/zY/02hk2RESrG+CD5HtTu6OFV9/TxzmhPUY9FuK P37U5LcypA5szVL350JT5649svkbjtlSeI/0/+HwkFyvWCQjrnO6IEmpP00WzxGi9vDp hmtpC1P8fxXKvUFIaU/PIPJasSrz+iQQyY3fXoka4SIrmmT5D4BAdyXL9bxj7ZNWze/I pZ1g== X-Gm-Message-State: AOAM533kqDvYb4tNoQuntYdypiwpqULI5n2O+Uki7Yf9hulkrDHVw6o4 l+qK1L84mcqnw3//LLyX2cvTW5uuySd0o3HiNp+qxA== X-Google-Smtp-Source: ABdhPJyE231MwA0PwTEiZMRLIPQSYzlYYMaMHyX7dns85rHLTln6OT9sFx5kxr480LEIjGUDCepuPN1o8M5KkOFxeXo= X-Received: by 2002:a05:6638:13cc:: with SMTP id i12mr6054871jaj.20.1622163952765; Thu, 27 May 2021 18:05:52 -0700 (PDT) MIME-Version: 1.0 References: <31b6c0c44cb385667287c826528ad422c6433091.1620849613.git.pcc@google.com> In-Reply-To: From: Peter Collingbourne Date: Thu, 27 May 2021 18:05:41 -0700 Message-ID: Subject: Re: [PATCH v3 3/3] kasan: allow freed user page poisoning to be disabled with HW tags To: Jann Horn Cc: Andrey Konovalov , Alexander Potapenko , Catalin Marinas , Vincenzo Frascino , Andrew Morton , Evgenii Stepanov , Linux Memory Management List , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210527_180554_126377_D1739794 X-CRM114-Status: GOOD ( 39.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 26, 2021 at 3:45 AM Jann Horn wrote: > > On Wed, May 26, 2021 at 12:07 AM Andrey Konovalov wrote: > > On Wed, May 12, 2021 at 11:09 PM Peter Collingbourne wrote: > > > Poisoning freed pages protects against kernel use-after-free. The > > > likelihood of such a bug involving kernel pages is significantly higher > > > than that for user pages. At the same time, poisoning freed pages can > > > impose a significant performance cost, which cannot always be justified > > > for user pages given the lower probability of finding a bug. Therefore, > > > make it possible to configure the kernel to disable freed user page > > > poisoning when using HW tags via the new kasan.skip_user_poison_on_free > > > command line option. > > > > So the potential scenario that would be undetectable with > > kasan.skip_user_poison_on_free enabled is: 1) kernel allocates a user > > page and maps it for userspace, 2) the page gets freed in the kernel, > > 3) kernel accesses the page leading to a use-after-free. Is this > > correct? Yes, that's correct. > > If bugs involving use-after-free accesses on user pages is something > > that is extremely rare, perhaps we could just change the default and > > avoid adding a command line switch. > > > > Jann, maybe you have an idea of how common something like this is or > > have other inputs? > > GFP_USER is kind of a squishy concept, and if you grep around for it > in the kernel tree, you can see it being used for all kinds of things > - including SKBs in some weird ISDN driver, various types of BPF > allocations, and so on. It's probably the wrong flag to hook if you > want something that means "these pages will mostly be accessed from > userspace". > > My guess is that what pcc@ is actually interested in are probably > mainly anonymous pages, and to a lesser degree also page cache pages? > Those use the more specific GFP_HIGHUSER_MOVABLE (which indicates that > the kernel will usually not be holding any direct pointers to the page > outside of rmap/pagecache logic, and that any kernel access to the > pages will be using the kmap API). > > It's probably safe to assume that the majority of kernel bugs won't > directly involve GFP_HIGHUSER_MOVABLE memory - that's probably mostly > only going to happen if there are bugs in code that grabs pages with > get_user_pages* and then kmap()s them, or if there's something broken > in the pipe logic, or maybe an OOB issue in filesystem parsing code > (?), or something like that. This makes sense to me. The pages that I'm most interested in getting this treatment are indeed the anonymous and, to a lesser extent, pagecache pages. The GFP_HIGHUSER_MOVABLE restrictions to me imply a lack of direct kernel access more strongly than GFP_USER, as you point out. Therefore I agree with Andrey that we probably don't need a switch for this and can just change the behavior for GFP_HIGHUSER_MOVABLE. I've done so in v4, although this required a preparatory patch to merge __alloc_zeroed_user_highpage() and alloc_zeroed_user_highpage_movable() so that we actually use the GFP_HIGHUSER_MOVABLE constant for anonymous pages. > Peter, is the plan to have this poisoning disabled in production? Is > there an estimate on slow this is? Yes, that is the plan. I don't think I'm at liberty to provide exact numbers, but given that the previous patches mean that at allocation time we only touch pages once whether or not KASAN is enabled, the most significant remaining KASAN-associated source of overhead for user pages is the deallocation time overhead that I'm eliminating in this patch. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel