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 F09AAC4707B for ; Thu, 18 Jan 2024 13:28:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7878B6B0080; Thu, 18 Jan 2024 08:28:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 710916B0098; Thu, 18 Jan 2024 08:28:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 514C46B00A4; Thu, 18 Jan 2024 08:28:41 -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 37DD16B0080 for ; Thu, 18 Jan 2024 08:28:41 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EAF70120CA4 for ; Thu, 18 Jan 2024 13:28:40 +0000 (UTC) X-FDA: 81692511600.06.12D1C55 Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by imf01.hostedemail.com (Postfix) with ESMTP id 3F97140010 for ; Thu, 18 Jan 2024 13:28:39 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3CpOYvxK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705584519; 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=MEsDDpNSu2lCDsHRoNgjF4HiSiukKKXSzyfx5Mkvc6o=; b=Zn/S8FCwFgSmjgxfE8uTqyhlFW2dzWUuTXUCazAxPsUvZl165GZnDJTbtViSdoCqLg6OF1 3X/nfcJqmSo1O8XFyLeGfo5ng90QqDV+giv7k+WnWrqF6d3HlbwvGO7I9r87/Hd3v6N57D ulAy2cSkWc8peOlIDGP8PZz90lRj8eQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3CpOYvxK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of elver@google.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705584519; a=rsa-sha256; cv=none; b=KSMyMi8+HUk758q2xavtnqpWVPG5cljIOq3wVO/2H67ZmLWPCp4YqrIV0aqeAAROb3kF9x UF3cO18qRurfRxfiJYgOnbbgqmJQXV8Q4/ktfHrzWUmSFqqxJvYDflTjd2d6I84+eZMvbb OY1sN0itEC+oi/O/xxxRtdoJZQlkTJU= Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4b71b86ef81so2543632e0c.2 for ; Thu, 18 Jan 2024 05:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705584518; x=1706189318; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MEsDDpNSu2lCDsHRoNgjF4HiSiukKKXSzyfx5Mkvc6o=; b=3CpOYvxKwTvZJyUvocjed94GvDC7No5x9P5ImDVvHLeokVP0IFgRCyOQxpZVXfji1v gF7p8J5kdxtxfXSBoJtaSD0XFghL4ysUaGWRqJ4YR96X5ZMl7fHhql62eHPl3e4t8Gd5 JO2bKbZ2bJmgAciY5c04OCJRxaJ/QObKNNDPNCd3crURSWJAZE+zFHrJBv5a5YtRWe3I 90YqjhRhqRhIAACoeTR/3EbjdRG/2nhZCG75saADrQx0UyHmRmaJt8+hNUJGsbLNWFyH U2GhluyGDtbyicL3biabxZGoTGwxq4UrWpGgt2y34dJf0SL4oRdGSQQFDltc8TVQ5g+9 6ZYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705584518; x=1706189318; 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=MEsDDpNSu2lCDsHRoNgjF4HiSiukKKXSzyfx5Mkvc6o=; b=Gz4wBrnR0QTBAjk2AnVe22/mhBwfw6XJZbmNk0zNX83ckvExSPl92nND9JIm+/+kCx qnaMl1zEbdvGNI+vJ6a5+lCevC5ZZ4LMQDbRRuJRJMT0mn5gTMuXfdaqrxcE9NmKYPuM 0iOUU1yJwGEu+8Jdlaid0AtLA/dTdxijuBkjpQdJNdTodPTGmuvrIMP8U/ULhq4V2St3 sjtMFvu5keM62rg3RZ6cByYrorEZhg/fZFopTbybDmU0DW8itMAvohNbGGup0VNWR4Yk QgyETSm36cS1ZUzYPrbkd2oMbzHX2+lL09c4vTZb+9pav4HluiKwRCL+/3oecrj5yPPy wAQQ== X-Gm-Message-State: AOJu0YzEQWiCyiwbRwbhCzM2S/j7UKu2oqQhFCNMdO6w37B7DS/FOGKx LUXnZ18gEjXI7p8dOOHT3UdNtNjgO/NCWkQPnB8jxbZb9fZG6K7PGimfQzC9p51pff1wMimxTgs sNAhGuGm1/aYJe9tHgpcTj/Qmn1nj1LJLFbyr X-Google-Smtp-Source: AGHT+IEHl8ux1Nn5x7P0PRKZkwEJl0cOhp4ooL57KEMNn5iE+g8p2cVB80wv4++Tbcf1RZvtE7j4aPtMwF+PjOMJFqI= X-Received: by 2002:a05:6122:a02:b0:4b7:40fe:3114 with SMTP id 2-20020a0561220a0200b004b740fe3114mr654124vkn.2.1705584518179; Thu, 18 Jan 2024 05:28:38 -0800 (PST) MIME-Version: 1.0 References: <20240118124109.37324-1-lizhe.67@bytedance.com> In-Reply-To: <20240118124109.37324-1-lizhe.67@bytedance.com> From: Marco Elver Date: Thu, 18 Jan 2024 14:28:00 +0100 Message-ID: Subject: Re: [RFC 0/2] kasan: introduce mem track feature To: lizhe.67@bytedance.com Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, lizefan.x@bytedance.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 3F97140010 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ti49y9kdh9oa8ub163uupauisoijkzh3 X-HE-Tag: 1705584519-384431 X-HE-Meta: U2FsdGVkX1/PspZhVhbOCZbmYIs5RJ0P8+Tq9Wy11uexvjDLneG2O7UJMODrilWUGss7yWyY4jWgI+XboBbeNBuipuW5Vx5xJa4DGwMSkzhXoz/WQ9VozfriVZ4K2UjETMNKQY1X/mAuS/6bgDh8FqlbEg1D0THzhjHTcXOS3P7xXj3GOO5QbBo7Ne/P6cKxyQeNz9TTtDphRtpVf3/fZyi/tdkSy2Fi2boOAoZ2VtUo2mnIz4AbQ79oH9s8IVDyvV3aw3l0P6aG0rhqpanIWIowcXUYT11w+cWUCPw9WaqH/eDVZvaVn1mdNFkIfEjXNBZOpT2ieG758xX4aSy6NVjt9+7XbHhsyiZ4sWYKCmjtSRSOmmQJe8ZnlEDVYW++Y627gKy5RTRz1eWtoYzFwf6ctaa7qkgCMchbV4uk0XkNk4NglkFd6A+vZyDt83WCvtULIq/hAJ2DPIv+djZKxFSRnzHdmwcRFv1aGi7MHVBJEngaPr+su5gBrLXG1fE8BVsZC25lq3qtP9zDelR69F+O3IbnXs5+8jUbSe7Nzb+VVNoDawMWEOt2PkLuZkmQA2Slk6Qpc2SoTiUbZHSgl8PqAKVQm8L85Ysf0laNnnGHNlFnxGzPq22IyH7gEZt88uryDk451MpfhaAWz7ESHq7WCMRD55PWLFvj53YF81QOtypskEeOBN9R7gmAlwJN77RP7YHbd7dYN6fkXXFlYHxiqenwuej9m19LCY+wzxNjd/sjfDIA2GTdhI+w/XbGSmZTGwJtUTHMsNMCG9CSPxzRgU836gtQVAm3Y5NaeH1O0U5J9KFpgwycFqZCCmlbcASHNJ4VApw7qKimR7vi8ZYW6hMc6TdZydqgQToe/q6MGDjBmSjhuqHEP/tteeFIGet8fRaSbfv1J5vWcmwSFAedIiHVNkwA6V798ucBbV3Y9I3HdhhmmFgKbYRD/LJ3dWVZnMJRw8N0Ird/i3y YzbeTIA1 lcdKg0BotXfUan8PqLC9PjSEr5xIJODqhEjqPUkVjEe0XE2d5eKRuU9gt6wu1EuyFjDUMHZSvnJ7FnkruDWundMPznzafAQuHgqS5thIYGRbEv0C6x4/XlwKHoDPiJfJxY+BXXIMQhN5Y16ndihFpvyhorCQ6KJA7/48eVczO9rk+3XdwccbZVILVSiAu+AaSeGrUyIrLk7zBmyi02//4CaETRruEoIm+c6twOCpRI9NuRxGU+iDiS7nxTmjWu76SUDC161/S0McsSV6VbmuQxEIh0nJQ1fcGK8RRTcon8TSscVCRnmm6ppJkfWXKEGvaZWxAru+N8dcEXyCqdzWkdcup0NQR6VjYEDYITMj8iY0WMkZq7TpDTg309hZBw7Yx00NdvLs47kYo59kuj/I10XQF2ZO3SH6Oxpfh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000653, 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 Thu, 18 Jan 2024 at 13:41, lizhe.67 via kasan-dev 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. Note: "track" is already an overloaded word with KASAN, meaning some allocation/free stack trace info + CPU id, task etc. > 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. It took me several readings to understand what problem you're actually trying to solve. AFAIK, you're trying to add custom poison/unpoison functions. >From what I can tell this is duplicating functionality: it is perfectly legal to poison and unpoison memory while it is already allocated. I think it used to be the case the kasan_poison/unpoison() were API functions, but since tag-based KASAN modes this was changed to hide the complexity here. But you could simply expose a simpler variant of kasan_{un,}poison, e.g. kasan_poison/unpoison_custom(). You'd have to introduce another type (see where KASAN_PAGE_FREE, KASAN_SLAB_FREE is defined) to distinguish this custom type from other poisoned memory. Obviously it would be invalid to kasan_poison_custom() memory that is already poisoned, because that would discard the pre-existing poison type. With that design, I believe it would also work for the inline version of KASAN and not just outline version.