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 DC48CC27C40 for ; Thu, 23 Nov 2023 00:39:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 710DC6B05CF; Wed, 22 Nov 2023 19:39:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C16B6B05D1; Wed, 22 Nov 2023 19:39:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 589476B05D3; Wed, 22 Nov 2023 19:39:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 494C96B05CF for ; Wed, 22 Nov 2023 19:39:54 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 247AF1CA7A5 for ; Thu, 23 Nov 2023 00:39:54 +0000 (UTC) X-FDA: 81487361508.21.7F53703 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf28.hostedemail.com (Postfix) with ESMTP id 39345C000D for ; Thu, 23 Nov 2023 00:39:51 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JxoaPjnQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700699992; a=rsa-sha256; cv=none; b=AkDCzUqhuzJankd5+ClfzafbrnHHCyK7+RyrqX3uZmJ6s08RwRtMW93a7c6NsCh7tM2c+D NabfktPYJLFKHbcJgOU39I5IM+tXDIoO+xk/i7zDlLyB1qFmgc4wmbgTDD/7Kka8RTFiEf wswz9y4eP2ycf0FF5eF5oWr5emYySuY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JxoaPjnQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700699992; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EwQlGsWYOqxIdXRKSpiAx1SqqlnvS6MmmN0ONz1p3kw=; b=ebmUlLA4XH8SYkyXED8LDiMigwxFNy1kT+Se7kGt4keLGaboTml3Di/pLHsBZIp5FqHWw3 tYAgosg7qr49fowxUm3lu7q6a2yFbK/Ai0ee9nr9L4/o4cmU9tgXScZHGS5nL7gc5LNIVA s57jk5btQyyYpICiKXg+obprIEZZC8Q= Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-4ac2c1a4b87so122456e0c.0 for ; Wed, 22 Nov 2023 16:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700699991; x=1701304791; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EwQlGsWYOqxIdXRKSpiAx1SqqlnvS6MmmN0ONz1p3kw=; b=JxoaPjnQfBAazsxjULp2zjWlbhc5Sb0PCRah//T7FLF2jQ4Tnm/HZOU4jbJUtg4yA3 ikzDDK4ttA9Ay7umCtG0YfQVqs3TEe6QIHdyAHCjejB4HSLsBoEp0hDIxul8h0N/dtwu qyVOdBFFytRlL82RjBXfSO5IPcjPVAFKu8YjiLDd72QCpyurn+vSQkHM3Cu4d/Sx0Pw+ LCaNT8N4EE7aZrFs70flVanvi/IJW2IAUDFMMbx1XuRgIQo4ufZUJ5eSraHybolZqW5i raKhlZcU1/htSLTFv7bZ4GqYal2a8uDdXeFPEMi5XsSKx8NkQx0KPrGcBlwMn5dKPlDO NhcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700699991; x=1701304791; h=content-transfer-encoding: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=EwQlGsWYOqxIdXRKSpiAx1SqqlnvS6MmmN0ONz1p3kw=; b=oRvynW+zPBc5OBsslIIZvVSGTWFGDWuzxZGkJxJOCpBZ2wroiareibZ/yoUsxxLHG7 xzB0SYs9X7KXHhk74bLLRo5BB31AqJKmYj1a63AwQU9isXBmtk/NEhREXRukO0sAOW23 yaEHfZ5x1f4oaFMYl078+5ABZEVS08BIO/IFRm18pt4gblC8RUBxcPZMJMR3PMQz4+dm NFFUYb5v7uCdzgSYOmZySVJ0fcO6Q92H0n1XXjaWgi6dOITLNZxIa+TkDgP4mW51Ixjg 2RDfNqyynY0HkCytHxlXDpQSrHQiDvPbAzAQcZ7vH1Jb5moSNc05YmRxOL34hcs1hYKy SEnw== X-Gm-Message-State: AOJu0YxYkHRvura0DYgbKJCo6PUJabFc3xxnIeW1A9ZnsB9B0U+dHHrc SdCS41AR9Rs+O2sObrzh4o/IfIfy7DHiBluMdYU= X-Google-Smtp-Source: AGHT+IEq7du79WE0HCEszn4TAAwpuHFwCiiAJe28LVauqC0P++29Al260qNAZ/zpmAXClF4k0a7dvbQ3EGfiisUn7kk= X-Received: by 2002:a1f:6244:0:b0:4ac:962c:c2ea with SMTP id w65-20020a1f6244000000b004ac962cc2eamr4289472vkb.10.1700699991089; Wed, 22 Nov 2023 16:39:51 -0800 (PST) MIME-Version: 1.0 References: <20231122231202.121277-1-andrey.konovalov@linux.dev> In-Reply-To: <20231122231202.121277-1-andrey.konovalov@linux.dev> From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Thu, 23 Nov 2023 09:39:39 +0900 Message-ID: Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning To: andrey.konovalov@linux.dev Cc: Andrew Morton , Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Feng Tang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 39345C000D X-Stat-Signature: 7jg94cq16ddq4gedmc7fqpmzhgtrpnxd X-HE-Tag: 1700699991-258683 X-HE-Meta: U2FsdGVkX19QlcIZ4o2Jzm5GBISRsOoJZTlxjDFdopSxr+2hxZrqTeDh67iJZtrrNeYINjLuLMKtJpOMQTroBmt5jbbBhZuUfeo2q9c2sGT31Ou4VIuOq4kHRdaZslc4nJd2/adAAvvcr951R9kNocJzjwjVm2eh66AQ6VwKHTezkVLw0VXgEkoJzgbcWAC7hRqKruaIrNNuLk+FtabKv/w9ApCtFeqMpYERS3k2GNKIJQ5PLIEE5YmhrEftNJWoqshQkMVXp30JpDW0zALFmBDgkpCIqg0zH6QYEMFB3Q4FybpRs+k+ynt1Y9cXzr/+gucSvC6KSC+095E0U5flOAQknosh6lNsXRklH9bC4tf0BEXIXGmJkm0s30Ku3UV5gkSzIPmfJyo7id+qJYl6TK5Dhr+YiAkm6Wxgc7ThhxJlCoH9EO2L3wC+oUSdzZ0PsdG2QGqBu40yTYn9W63ppVLvhcKZl5Bq2gHTpm7DmDxgtoSSQJmGrkA17SwdPAP37GSy6oSBXVsOKkFWge4kKvzo0B5zt6MJd/+S4jqUC+BebSk5UeHLLTSma9+pXBGCA8cupAMs+LTf9ry3dzQYlWENKXT5cfYo/ldzjuKEc+U+XOI06JhaNGBosnTRrAZfnuimsg4d3Uw79OJgTjtzoWe3d+Qt/fEBYthBJYJGXuGbMHQrTj1/ypuLYZwqqO4NXda9p/mQsGffzXIAh0+Mc/GBBQJmjleemAI0D4gSnfG4/s9azG3Y8F8iDCUj8IcjptN+HQKtZcWcDwOJE4FWk4qFhf3yMpbVZv/CEGQYmnXrsG3UzV6DF6hmE44xA0FJ9jGKyBM3r6gHDu6hTqz3YVGG2GCQjgqL1aKKFX/5ENvOuWwen2devtiwiB9VmGPl/nc+ov2oAAcpVj02c8yqEqjgs/uqGkle/nNh+SkiwfHbNXFWx2A0YqCTAvRTbkgzLchzDNeaxhIatjYuzxn 8hwaH0TE gVGyxwXHzOpUhiCZYOXfadJFP72nrnZaXuhSD/5tu1zvXgTDzKl8lRsus3c3TLiw63xa9t8YiIJL4wbLWQQMn8FX7OmO+RaWGiG0zQCdklXWrcnKZADb+pnul9wTi1T6gDl3o4nShD4UpCSWvDrogX/agFJET6T/4UWGTNfyvTwuiXBVAtyN2DwowaP+Qp03X6p8sKLUAi1lQkZIeQL+HBuAje4WWWMrUV2VVkrjr7weRtAvG/mLMl1MJ9D42yzFfAo//Xa5fFmx4M87oMfAgICy93gv/vgxMNS0g591uoqStObB2k4LI0o0CSwHgUPoJ3x0Q0PJaOAu8GPVBGg5wgJrF/PmMFnWTiqnmE4NsxWfDrRLjRkZ/3j1RLwyfHU8hVlDUQvY9H9XrBo8ROVoVvoI0F3jSUwmAhC4PyRoNXPK2nVgKT/vGCE5MfYeJJ57EvtX+Egj9Ds3Za748pcmncVKhR4s/iJFYJ5hG/C1HYWjrMJM= 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, Nov 23, 2023 at 8:12=E2=80=AFAM wrote: > > From: Andrey Konovalov > > When both KASAN and slub_debug are enabled, when a free object is being > prepared in setup_object, slub_debug poisons the object data before KASAN > initializes its per-object metadata. > > Right now, in setup_object, KASAN only initializes the alloc metadata, > which is always stored outside of the object. slub_debug is aware of > this and it skips poisoning and checking that memory area. > > However, with the following patch in this series, KASAN also starts > initializing its free medata in setup_object. As this metadata might be > stored within the object, this initialization might overwrite the > slub_debug poisoning. This leads to slub_debug reports. > > Thus, skip checking slub_debug poisoning of the object data area that > overlaps with the in-object KASAN free metadata. > > Also make slub_debug poisoning of tail kmalloc redzones more precise when > KASAN is enabled: slub_debug can still poison and check the tail kmalloc > allocation area that comes after the KASAN free metadata. > > Signed-off-by: Andrey Konovalov Thank you for looking at this quickly! Unfortunately the problem isn't fixed yet with the patch. I applied this on top of linux-next and built a kernel with the same config= , it is still stuck at boot. [dmesg] [ 0.000000] Linux version 6.7.0-rc2-next-20231122-00001-gfc1613c2f6f3 (hyeyoo@localhost.localdomain) (gcc (GCC) 11.33 [ 0.000000] Command line: console=3DttyS0 root=3D/dev/sda1 nokaslr [ 0.000000] RIP: 0010:setup_arch (arch/x86/kernel/setup.c:443 arch/x86/kernel/setup.c:665 arch/x86/kernel/setup.c:81 [ 0.000000] Code: b6 0a 08 00 48 89 c5 48 85 c0 0f 84 58 13 00 00 48 c1 e8 03 48 83 05 4e a9 66 00 01 80 3c 18 00 0f3 Code starting with the faulting instruction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0: b6 0a mov $0xa,%dh 2: 08 00 or %al,(%rax) 4: 48 89 c5 mov %rax,%rbp 7: 48 85 c0 test %rax,%rax a: 0f 84 58 13 00 00 je 0x1368 10: 48 c1 e8 03 shr $0x3,%rax 14: 48 83 05 4e a9 66 00 addq $0x1,0x66a94e(%rip) # 0x66a96= a 1b: 01 1c: 80 3c 18 00 cmpb $0x0,(%rax,%rbx,1) 20: f3 repz [ 0.000000] RSP: 0000:ffffffff86207e00 EFLAGS: 00010046 ORIG_RAX: 0000000000000009 [ 0.000000] RAX: 1fffffffffe40069 RBX: dffffc0000000000 RCX: 1ffffffff12= 30a30 [ 0.000000] RDX: 0000000000000000 RSI: 0107d62120059000 RDI: ffffffff891= 85180 [ 0.000000] RBP: ffffffffff200348 R08: 8000000000000163 R09: 1ffffffff12= 30a28 [ 0.000000] R10: ffffffff89194150 R11: 0000000000000000 R12: 00000000000= 00010 [ 0.000000] R13: ffffffffff200354 R14: 0107d62120058348 R15: 0107d621200= 58348 [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff88f75000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200348 CR3: 0000000009128000 CR4: 00000000000= 000b0 [ 0.000000] Call Trace: [ 0.000000] [ 0.000000] ? show_regs (arch/x86/kernel/dumpstack.c:478) [ 0.000000] ? early_fixup_exception (arch/x86/mm/extable.c:364) [ 0.000000] ? do_early_exception (arch/x86/kernel/head64.c:423) [ 0.000000] ? early_idt_handler_common (arch/x86/kernel/head_64.S:555) [ 0.000000] ? setup_arch (arch/x86/kernel/setup.c:443 arch/x86/kernel/setup.c:665 arch/x86/kernel/setup.c:814) [ 0.000000] ? __pfx_setup_arch (arch/x86/kernel/setup.c:728) [ 0.000000] ? vprintk_default (kernel/printk/printk.c:2318) [ 0.000000] ? vprintk (kernel/printk/printk_safe.c:45) [ 0.000000] ? _printk (kernel/printk/printk.c:2328) [ 0.000000] ? __pfx__printk (kernel/printk/printk.c:2323) [ 0.000000] ? init_cgroup_root (kernel/cgroup/cgroup.c:2054) [ 0.000000] ? cgroup_init_early (kernel/cgroup/cgroup.c:6077 (discriminator 13)) [ 0.000000] ? start_kernel (init/main.c:897 (discriminator 3)) [ 0.000000] ? x86_64_start_reservations (arch/x86/kernel/head64.c:543) [ 0.000000] ? x86_64_start_kernel (arch/x86/kernel/head64.c:536) [ 0.000000] ? secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:= 432) [ 0.000000]