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 7D39FC47258 for ; Tue, 23 Jan 2024 06:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CFEE06B007B; Tue, 23 Jan 2024 01:28:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CAF6C6B0080; Tue, 23 Jan 2024 01:28:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B77366B0081; Tue, 23 Jan 2024 01:28:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A8BAF6B007B for ; Tue, 23 Jan 2024 01:28:08 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A8A3C14078D for ; Tue, 23 Jan 2024 06:28:07 +0000 (UTC) X-FDA: 81709595814.23.DB85AB6 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf04.hostedemail.com (Postfix) with ESMTP id 2154D40002 for ; Tue, 23 Jan 2024 06:28:04 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=YcjTN5Aj; spf=pass (imf04.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705991286; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wiLvfLf4OGeDGMn4ocLXudOpmwX+r0wZE0fc2HKgdsY=; b=HDxOY3QdErPrHVUhVxrbl0rzoBsct5lkHgyrjBD4fOyStSZznFigQj2lhRalBUYQHr1XIY SNLHhqoL7J2CniE8jcM/0GdfRbOWtGoNJR77ne1MHej5eXEenkqjXz7rfvP363GLQLFxEW CF7yql79MaMJXCsag8yPMLKS9M8QOW0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705991286; a=rsa-sha256; cv=none; b=KvlXU8HI8hN9QBrZY/VLU7VWrd59z116ZxeWFNqtIxCxl7bCJHXElcsUAWvQ/JTXxhUczw YZ95KzQN/Tdqedu+wzCRi4LQjVc5AnlFXdhLfG3wgvF8HCcdC6WqOwsYJIB4AwG4ma64Wi 4C1se5zEolIGwH2bH7vAIH0OdDBSWcE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=YcjTN5Aj; spf=pass (imf04.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-5cde7afa1d7so1852487a12.1 for ; Mon, 22 Jan 2024 22:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705991283; x=1706596083; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wiLvfLf4OGeDGMn4ocLXudOpmwX+r0wZE0fc2HKgdsY=; b=YcjTN5AjR6qDR1UA9LqO1p5bkd8c99f3bynmMQClkUuC3OyE7lC6X/QjSKOkST6KVY nM3eRBye6fZJT+GxE5jfoHTaSCMdIm8xuBhQYFLlcuWRBbYRirz1kmumKL7o7oGG/AxX NsQuC4+8snD/jcL2reB2uztCWVMB+yUNpozBXLT2VAXBIvUnYN/QW7d65Y7AY6axoucl lkZHLeV7eRra9CRJjtvy3Ug8XbComqkxhbYGS7dNnfqkAcEyKFDVt62JXx5+T1NUN1BT rigZ4hjGGrX5s1K8zTaul+KdaLyndA5Izzo6/QKE8fnyqfHUm+RTdZFPcRKDBZX58kD9 JIiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705991283; x=1706596083; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wiLvfLf4OGeDGMn4ocLXudOpmwX+r0wZE0fc2HKgdsY=; b=iCYYTu6pPsqilZkbnYEef+GdyhcU1n3oaVsxIoMqhcOEBqWCD4JRwIrP9aXyAa3SwS b42vYWYJ2n3VwC1mp0oE2HR6A7iHmfUBbfdPsvX2/FyReaM/oMeX4/z4x5fk4Dh94n27 PuqKdTfMbOgjAaAf51Gl3Ryo00/TSALaVsEJcsfZTWPYiV8s/ChNns7XhWTXXqC7cNdt h1NVGixBAyavNbq+/MYmcJYGdPRrXTxIYPaN23eBtAuJNwJvdw5s924sroULZWWLWdZC Opi1Uw+OFkBhcB0nFhl1rwwPmWrWcZpiNgFrViPuHT3pInehk2SRcCA3SWXpmFM2xkOP l68g== X-Gm-Message-State: AOJu0Yws6vkG5KLy3PUsvwBoBLfSdUBJhjxT7SFcef//XK51648UquSM 2pJWKVf5yiNVA4fv13wX+EEKWZ/J2nWP6K/3i5K6A27Xfv8t/DUfcwav7lkjE69XDDY4xCNUTLL 93Bc= X-Google-Smtp-Source: AGHT+IGpWs/GhHYYVao8/u44xfJdsv0BHPKaR9SHQ/wW5SUs5P3Y07vKdehIf9S7QaCBXxlZct0sEA== X-Received: by 2002:a17:90a:86:b0:290:cef3:822a with SMTP id a6-20020a17090a008600b00290cef3822amr350946pja.90.1705991283601; Mon, 22 Jan 2024 22:28:03 -0800 (PST) Received: from GQ6QX3JCW2.bytedance.net ([203.208.189.7]) by smtp.gmail.com with ESMTPSA id pl3-20020a17090b268300b002909eb075dasm3502608pjb.8.2024.01.22.22.27.59 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 22 Jan 2024 22:28:03 -0800 (PST) From: lizhe.67@bytedance.com To: dvyukov@google.com Cc: akpm@linux-foundation.org, andreyknvl@gmail.com, glider@google.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, lizefan.x@bytedance.com, lizhe.67@bytedance.com, ryabinin.a.a@gmail.com, vincenzo.frascino@arm.com Subject: Re: [RFC 0/2] kasan: introduce mem track feature Date: Tue, 23 Jan 2024 14:27:56 +0800 Message-ID: <20240123062756.87505-1-lizhe.67@bytedance.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 2154D40002 X-Rspam-User: X-Stat-Signature: sfm5s448tyugaezouj18ihza85dpueoa X-Rspamd-Server: rspam03 X-HE-Tag: 1705991284-197224 X-HE-Meta: U2FsdGVkX1+iMvKar2AAxEBkBEbjjBxrQWhYNq5NhQl7L/CpZdI/9rSmpu85Gba/y70JYuDqFURaD1dz53o6AYAJQFffVC+WVN0mmbzF3WZQ3k/bs3DiE1SC5lAxQSpF0SnSuVwm6q44C0SLycJsN+6cGc1czRScuVcf7M8QMeTRLaX1WIPiYxLcHAAHrG+Psyy5OHiLwXQC2kHv/curg/SwrFpV2L7gAMuc9Gx84MOZBE812YofMfJo98htU3Yd8tPGa0kTr6tp83tEbZeS1AZYlKG7M+0Oyy+vVvdW8i34QeQsTCOHBcjyiHJi168QFcN5x2yH4wYP4MjKsTA2oyRGCWBprcefyc3mhPyyzGC+OeZ7eQvoR3RtG4/ifbPMfYepnv/BYNn5IrkNvmfjCcpswk1Um2tI6ZpIC743tMK7cXqSgWkgEt6cPleviQoIHPOfAIKec0i5kvDPVAyM5Oq0+r/ubF3+n2dnToq62zEuemz6w1+4wgXrN+7+WX1r7IAFqRMUeHNXKJx2rHNfl1IubDrqqKtKHWmTcfy19xmlbodB6LxqsO+abjDh5aUSjpw+w6/dx8NEd9DhclDkRjfWAFs20frMufMLMZzlfX8nBXURMvu61ExU1OJUbXubOXB2qpob1jmuLvIxexva6JfL958vdP+oy0Ixjktr+7IzmW7Iz+5KUkvUKnq/SXwdaf2/I/1lF+LqdggxFFJjD6OOJ4dY6yqc6h6Fm36LNFOpce8sUQtIE4WW7LDHheDHlNEAvOjYTrroWSNfwFTAH5LpYalaN+J405cDewkimA45sK77YHgLIF4sSrMo/g1mJd78Ix5wnUMaMgwVa2nC3UITi4cLUpbPGL9qHD5IkcuHJKg59RuATEJT+yM2BEazHN9Za2jIiR2AUxtOElpJ8WJZAhXePaSaugCKF5I6DorfdZZ00zqoHqLQmnOhSN+V/r8Nkez080BeoeZQmxR 3Rb+Sryz TNF47/+exLt/fSgTyikzsSBe+SA9ssT1w55nciqbCiXAWUquPc42IRdJpvGiY1yDOEI8MxpOJ9rzOtY3FBqkuryrR4PnvP9TH5CQe03bZOq+IFB56VqHaG8FdGgjyAYBpf8KPO2qP6WEOSCe4A9C7Spps6dDBW+ZeB60pFY+mMRz0Dqn3OLnC/zlKzxmDduIo4ICqda7o6+CwEPs= 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: List-Subscribe: List-Unsubscribe: On Mon, 22 Jan 2024 08:03:17, dvyukov@google.com wrote: >> >> From: Li Zhe >> >> >> >> 1. Problem >> >> ========== >> >> KASAN is a tools for detecting memory bugs like out-of-bounds and >> >> use-after-free. In Generic KASAN mode, it use shadow memory to record >> >> the accessible information of the memory. After we allocate a memory >> >> from kernel, the shadow memory corresponding to this memory will be >> >> marked as accessible. >> >> In our daily development, memory problems often occur. If a task >> >> accidentally modifies memory that does not belong to itself but has >> >> been allocated, some strange phenomena may occur. This kind of problem >> >> brings a lot of trouble to our development, and unluckily, this kind of >> >> problem cannot be captured by KASAN. This is because as long as the >> >> accessible information in shadow memory shows that the corresponding >> >> memory can be accessed, KASAN considers the memory access to be legal. >> >> >> >> 2. Solution >> >> =========== >> >> We solve this problem by introducing mem track feature base on KASAN >> >> with Generic KASAN mode. In the current kernel implementation, we use >> >> bits 0-2 of each shadow memory byte to store how many bytes in the 8 >> >> byte memory corresponding to the shadow memory byte can be accessed. >> >> When a 8-byte-memory is inaccessible, the highest bit of its >> >> corresponding shadow memory value is 1. Therefore, the key idea is that >> >> we can use the currently unused four bits 3-6 in the shadow memory to >> >> record relevant track information. Which means, we can use one bit to >> >> track 2 bytes of memory. If the track bit of the shadow mem corresponding >> >> to a certain memory is 1, it means that the corresponding 2-byte memory >> >> is tracked. By adding this check logic to KASAN's callback function, we >> >> can use KASAN's ability to capture allocated memory corruption. >> >> >> >> 3. Simple usage >> >> =========== >> >> The first step is to mark the memory as tracked after the allocation is >> >> completed. >> >> The second step is to remove the tracked mark of the memory before the >> >> legal access process and re-mark the memory as tracked after finishing >> >> the legal access process. >> > >> >KASAN already has a notion of memory poisoning/unpoisoning. >> >See kasan_unpoison_range function. We don't export kasan_poison_range, >> >but if you do local debuggng, you can export it locally. >> >> Thank you for your review! >> >> For example, for a 100-byte variable, I may only want to monitor certain >> two bytes (byte 3 and 4) in it. According to my understanding, >> kasan_poison/unpoison() can not detect the middle bytes individually. So I >> don't think function kasan_poison_range() can do what I want. > >That's something to note in the description/comments. > >How many ranges do you intend to protect this way? >If that's not too many, then a better option would be to poison these >ranges normally and store ranges that a thread can access currently on >a side. >This will give both 1-byte precision, filtering for reads/writes >separately and better diagnostics. OK I will find a better method to solve this problem. Thank you! > >> >> The first patch completes the implementation of the mem track, and the >> >> second patch provides an interface for using this facility, as well as >> >> a testcase for the interface. >> >> >> >> Li Zhe (2): >> >> kasan: introduce mem track feature base on kasan >> >> kasan: add mem track interface and its test cases >> >> >> >> include/linux/kasan.h | 5 + >> >> lib/Kconfig.kasan | 9 + >> >> mm/kasan/generic.c | 437 +++++++++++++++++++++++++++++++++-- >> >> mm/kasan/kasan_test_module.c | 26 +++ >> >> mm/kasan/report_generic.c | 6 + >> >> 5 files changed, 467 insertions(+), 16 deletions(-)