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 77717C4707B for ; Thu, 18 Jan 2024 14:30:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2C7F6B0085; Thu, 18 Jan 2024 09:30:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDC856B0088; Thu, 18 Jan 2024 09:30:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA4B56B0089; Thu, 18 Jan 2024 09:30:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CBF406B0085 for ; Thu, 18 Jan 2024 09:30:23 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 994F91A073C for ; Thu, 18 Jan 2024 14:30:23 +0000 (UTC) X-FDA: 81692667126.14.0825A57 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf15.hostedemail.com (Postfix) with ESMTP id CA8E7A002B for ; Thu, 18 Jan 2024 14:30:20 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=kMDB0Bhr; spf=pass (imf15.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.182 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=1705588221; 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=N3C5sTiWMzIfhZ6qTPUb3ie9E/4j8GA/fiWbUnWQwt0=; b=XdKi4X5ndM9+Ivqjj5+3b51IBZ3u7ZY1Wl/NEICsar6NWhwRD6saaaGMuX/Q5AwiLLj6tP mnkVfXSe6MaxLPzBldSpjaSGjlXeJiAoVoBLLXRzrm1zWLH+cYr8NWQ3pDqgmueYKYqrQZ YZAGsg6h5cdP+iYuzk4iMub8cCvKNWA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705588221; a=rsa-sha256; cv=none; b=TwfGTBFKRS5nXrl2YWdQb0b4qb5frYZwn2NOKBvu6e9eBW3MHFayHPSezuV05hMqfqhbBP NQB7owohEXm8lszA0vW0WwVQFj1p+P34LIdRkN0f/RtW4uMSiZ5VyAZJelxFJR/rExkSrN 49IryPsejBtO+0+7z7ycnOHArNCOcdE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=kMDB0Bhr; spf=pass (imf15.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1d54b765414so85795295ad.0 for ; Thu, 18 Jan 2024 06:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705588219; x=1706193019; 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=N3C5sTiWMzIfhZ6qTPUb3ie9E/4j8GA/fiWbUnWQwt0=; b=kMDB0Bhr0CZboPxdEt3YwTI5amKCQnDWx11vnHP+htj0zuqlMrXLaVgtM8lDwPkpSj zI0tWwvskqj6nmINx6pHpFrIairBXPB8COtlfYeePCtSIScXBuzyKU7Hqak8ZVs/N4ao OdJrD7wNWrDqpocAk01yDt+57rYYjTxz74/8d68GmQJSFKt5ZbxZx4YI4Wr2p5mSvBvp K0G9lIRrtKQlXs/wWmbM08rRT1tW4qrH3xUmAWEqcKQIKgNbiOj3BeP68dPwoc7Wmnxw zkihNaxOaKBGZ0fzbzbrMHGYG4bpcg9wg+2X2dcQioy7mNgj1T47/e2+t+PVLXZ2tjCs 5DXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705588219; x=1706193019; 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=N3C5sTiWMzIfhZ6qTPUb3ie9E/4j8GA/fiWbUnWQwt0=; b=nF9N+BUwDJAo/5L3IMRs0a0hYNolQp7uK/po3U9r20eV4UednMY41RPP1idPJu/15d kwF18Vq9BpOCOcwDOvk74FjQms5pOkcxQN046E0J5BnpYoK8vJKS9A1ybO5/O1kqztWS blxtElIJ6Z2X23JtLuBJ7i5J2pyGsElEsVIYW045paLPrBcC+B9mpSG48JFVsx/vl2or e9Aa9vokbnmQuXYuPnmKmCi0bSk5U3hJIU9JyPYW+oT93dXqB0f9sCqFKYsZ1ORaWPNF C6pTDnOW9iB8XA2ilkEP0sOvxWrf00UFgFw/xCxQRDmSnMG/hMrALQHroqh8TvrQXe33 lbRw== X-Gm-Message-State: AOJu0YxCMUqPHYp4cYJYniMANyPJZp3hZICec8wvXRnVx7GNIrAZE2fJ ye6ZBmJgCID7eWeJDLpdX2SVJzejeNhbJr1YpE8OufYYxhys1xsmaBDFzoI5yoQ= X-Google-Smtp-Source: AGHT+IFu8XpPv4bqp4And9tAXjD/ThHjVQzafsvfS+ja0lxIpUEvTlIsTz3tqG3OxKwuxyj4Miwssg== X-Received: by 2002:a17:902:9a42:b0:1d5:9983:bf74 with SMTP id x2-20020a1709029a4200b001d59983bf74mr774348plv.105.1705588219253; Thu, 18 Jan 2024 06:30:19 -0800 (PST) Received: from GQ6QX3JCW2.bytedance.net ([203.208.189.11]) by smtp.gmail.com with ESMTPSA id mf3-20020a170902fc8300b001d6f0e6095fsm1466233plb.197.2024.01.18.06.30.14 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 18 Jan 2024 06:30:18 -0800 (PST) From: lizhe.67@bytedance.com To: elver@google.com Cc: akpm@linux-foundation.org, andreyknvl@gmail.com, dvyukov@google.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: Thu, 18 Jan 2024 22:30:10 +0800 Message-ID: <20240118143010.43614-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: CA8E7A002B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: kxc7hsgu1pqh6tmu961w471yzuc6r6yi X-HE-Tag: 1705588220-87300 X-HE-Meta: U2FsdGVkX1/Q0v4pv4FlOSFP/xMkokmB1c5Cspwrw+u981PxuCYKm8V0r5orKXZZARttAFeW/+tLfS7BhQdQeNk6R7YW9AHkT44UuQFkaG0MMFJ3JS6xpUtvU0p2c/rg1DDU+ISh1XR0YXs6pu5/0fyVstn6cRjaRyKvjzbl9rxPBcLBk5ikypYOYDQp+9wuoZnEUrHnSJmALYZPSJA/pWDRlo2r2/IJ22Tc8RzAFsbK21zQKoKgdJ8mEOUOlLQRAtvXr5+Lyy2qYISLcn14Sgn14iwof2YC7usjNcwyDH052Ak7Kc+Je4nlLoj0Uf6v27F2822xUkdccAhp0WJt5n+4KMjM8o2OeEoYGyFqySCBBRdTqxri6owFc2h4OnNUDBZkoMxI2sbY/GPMDSivUiKv5ZB1+RKYEmw3cPIPNAdw+Fu0NG81tLrjZVc+HZ1MMCMdW+XwwUeNY7u0tKrJg6No5mWZGatWa+a4XVHw71xOWiu2n27TLBFj2kGNAcCUhbiBdS/7ciTeN5iU1JYQB924Syvwan+VAdeF9mIZY6e+zeE5A9TtMwT6kUWNdg+KZAJXX0ZEnt+YrFs/ZrPhSgYVcWoofpxYC6BbczBF2bvr4AP0YLmvPlK6mIIFlp+7pHUkYIGNWwo67hkh5x6ROfNDhOKdQSuqWbe+jmimIAp0GojvVhPR7Mrz8ovpJ5zQX5TGao0XWNFUzFNXiCoBHoIZv+vj/Nm5SKvBzyJjJLvuzwv/f03Zl23jMAeZ/sFurz3LRm8tCsLT12OQIiaR7uyHo9OGDbMPudNYAXMIx2xdX3DaESfbS7E8InGGur+lKIfw8DQO3cLgNJx71JXh3rKlBpBopoI6gC0OFAdueT5MipcL0ABVqZiYEnDwBpefyrnecU2mdWBqv9k49YcGP4bEYGw5Y0HxOgHjO8r3cuPuNJ35MVsLQVvHKfDwcmF1r2NOWIzzBEHA9f0tenH 6D6QiyMw bju2qEfcL+25JW+l0QzrBnRNN+FoSKRv2hoLDJFPPKhIjIUUxIxjPNEqDr635g2M1CUTatkl7BZ5lGaIEw47nk3Hy0am3khjNk82DO10Wts0OWKvrC03RNTUPNnVTYlo3GtJwEWo7D2AdmaQln3T6HS7xInjnBF+5nsQ8aCvONvt09Qqmhb6xNLLZ4/roeiodR5LiUMar3Zyc28fTx8uIULtMH3AnS2zNOwYjts1omyki7F/XSn+MLnqO2gADLVQJXAaMbmOkq+eMAqE+hyJVo9NkVsKPX3vhKyXSw2LvaZ5mVdKEQpoFJacFwRtnlKBzwcNzQhqruJzVgosCGaWQlc6ozRLoSmqRdte74LSVEIBSMpUoMTZt42vFOnVNjjmGQOPvN/cCdAXXXhb7M/pf6a+OdFhWwYf645TKQyuW5nhb+qE7FgyvRx+GEkV3aYHWDkfP 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 Thu, 18 Jan 2024 14:28:00, elver@google.com wrote: >> 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. Thanks for the reminder, I will change it to another name in the v2 patch. >> 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. Thank you for your review! Yes I am trying to add custom poison/unpoison functions which can monitor memory in a fine-grained manner, and not affect the original functionality of kasan. 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/unpoison() can do what I want.