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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C4DBC4321E for ; Wed, 30 Nov 2022 19:51:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C45D6B0074; Wed, 30 Nov 2022 14:51:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 675516B0075; Wed, 30 Nov 2022 14:51:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5642D6B0078; Wed, 30 Nov 2022 14:51:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 484876B0074 for ; Wed, 30 Nov 2022 14:51:48 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1A85FAB964 for ; Wed, 30 Nov 2022 19:51:48 +0000 (UTC) X-FDA: 80191153896.08.18D2641 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf19.hostedemail.com (Postfix) with ESMTP id 8DE3A1A000D for ; Wed, 30 Nov 2022 19:51:47 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id b21so17736906plc.9 for ; Wed, 30 Nov 2022 11:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rm61ltPf4IuMIek7hP38S0fd3od46k0u59OV/A4SUFE=; b=YPf0G8XJ72iHOC7HvWB7gUt6vwg2o+gvktb7yvputiaCaIey4xljHaDirr04vtz4nk w/kbuvDTJlraxX6CW7xM9IpLSWKiU+jd42zuI2twiV5dt9AmqgLE6nBiYTQC5hd0p3Mj NyYaNrTXkAuB+v42dOmyRgt+w4kMdLN6aoI9F/BTqbP8PT/xmvdRoWXbOc5I++Uv2qiH bQm7t259LLSxycIL8fRvm/FVyC/PbHbVLu9Bo/8LtDp7/hoei2igJRiHDSanP23h4WDG 1eHs83TWLRWjHjRaDb0H9uimCzZvnGIH89l7KHvu+kE0mGYqSbNJ27+VKISbjBQrWg78 rXAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rm61ltPf4IuMIek7hP38S0fd3od46k0u59OV/A4SUFE=; b=UaA0EkE8WYKuD8o99+jXRZqfg35xXBzFoDRNJ1OKpKyi5C4zv7F5/5ZFpoWGwa6aPY vCV8XvZ7/mi3msyMJ6nrcRN/psv/CqzGR2FJJBGXISI5tvatmnmbCmhhEXz1TumjCiKo NfPaK+iFHiaiORhw31zv4ZfTo+KfxTGsIuyBSMYzcENznIVl7e+wZONXUt3qd2JZFtwb 5t9gpjOHw74K27di/qrQST3B1uJZdrtEOgCHVFXlasT3h0sMKIY4h2DDdJBg4P4A5nO6 TLGC+6vA2SXSOzzqVCW4SyTPac8nV+rv40HN9laKfoI7XAVU2mxTtwLWVB4RTTWvVtww PQnA== X-Gm-Message-State: ANoB5pkMea1Hq7Ci+qiYPHLSYZpGIlZ3qm/FlLXK2PcnbW5QoZbZEIPJ SrAxFmD/KNnRgtCfih7nwesaTiQNFnl7Uv593dw= X-Google-Smtp-Source: AA0mqf446LWZq/SOD5Gg304JaLNU8xF7uR55IfibkGOcKLkjM/1PSNgGbWfF8JiqPIvtLyB43VrzvncGd5yIJWHo9fE= X-Received: by 2002:a17:90a:5298:b0:217:e054:9ac8 with SMTP id w24-20020a17090a529800b00217e0549ac8mr73320400pjh.246.1669837906527; Wed, 30 Nov 2022 11:51:46 -0800 (PST) MIME-Version: 1.0 References: <4c341c5609ed09ad6d52f937eeec28d142ff1f46.1669489329.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Wed, 30 Nov 2022 20:51:35 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] kasan: allow sampling page_alloc allocations for HW_TAGS To: Marco Elver Cc: andrey.konovalov@linux.dev, "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, Peter Collingbourne , Evgenii Stepanov , Florian Mayer , Jann Horn , Mark Brand , netdev@vger.kernel.org, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669837907; a=rsa-sha256; cv=none; b=jink2TNlFtw8Kak16wloVRLOfXZ5YHq3zH/KaX6hoG4YeM5blubi6xhZGppi5aMoWmfvQj UHA/x7yUHeW8EuK0t2OZ6ouncAcFdZp2xuU3E0XKS69JPslP91Y9a9jpB20/k3SGp22clS vV5GIjcdp9FPEIQS/3jhgEX7W7IPucc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YPf0G8XJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669837907; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rm61ltPf4IuMIek7hP38S0fd3od46k0u59OV/A4SUFE=; b=V022GdmXBKp0s9KHnMobHUQ8apSnypniU5EOTTWhHfkF61fnvz3ATXOoIwTYzla9+Nb10S lcdbIzoQWEgQW7tMTgilBy/J4oaY0mIV+fJ84Suf0sjHbNtlj1dF9V9XK6No5ZjYxR66na vnWphkH1+QZKfRZ2GK/xF5nzEHsJzZc= X-Stat-Signature: 5ffzzogcwxyocje44irxmyiir7eodwn7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8DE3A1A000D Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YPf0G8XJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspam-User: X-HE-Tag: 1669837907-713452 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 Tue, Nov 29, 2022 at 12:30 PM Marco Elver wrote: > > On Sat, 26 Nov 2022 at 20:12, wrote: > > > > From: Andrey Konovalov > > > > Add a new boot parameter called kasan.page_alloc.sample, which makes > > Hardware Tag-Based KASAN tag only every Nth page_alloc allocation for > > allocations marked with __GFP_KASAN_SAMPLE. > > This is new - why was it decided that this is a better design? Sampling all page_alloc allocations (with the suggested frequency of 1 out of 10) effectively means that KASAN/MTE is no longer mitigation for page_alloc corruptions. The idea here was to only apply sampling to selected allocations, so that all others are still checked deterministically. However, it's hard to say whether this is critical from the security perspective. Most exploits today corrupt slab objects, not page_alloc. > This means we have to go around introducing the GFP_KASAN_SAMPLE flag > everywhere where we think it might cause a performance degradation. > > This depends on accurate benchmarks. Yet, not everyone's usecases will > be the same. I fear we might end up with marking nearly all frequent > and large page-alloc allocations with GFP_KASAN_SAMPLE. > > Is it somehow possible to make the sampling decision more automatic? > > E.g. kasan.page_alloc.sample_order -> only sample page-alloc > allocations with order greater or equal to sample_order. Hm, perhaps this could be a good middle ground between sampling all allocations and sprinkling GFP_KASAN_SAMPLE. Looking at the networking code, most multi-page data allocations are done with the order of 3 (either via PAGE_ALLOC_COSTLY_ORDER or SKB_FRAG_PAGE_ORDER). So this would be the required minimum value for kasan.page_alloc.sample_order to alleviate the performance impact for the networking workloads. I measured the number of allocations for each order from 0 to 8 during boot in my test build: 7299 867 318 206 86 8 7 5 2 So sampling with kasan.page_alloc.sample_order=3 would affect only ~7% of page_alloc allocations that happen normally, which is not bad. (Of course, if an attacker can control the size of the allocation, they can increase the order to enable sampling.) I'll do some more testing and either send a v3 with this approach or get back to this discussion. Thanks for the suggestion!