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 6851BC2BA18 for ; Thu, 20 Jun 2024 11:47:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE7E66B04AF; Thu, 20 Jun 2024 07:47:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B71256B04B0; Thu, 20 Jun 2024 07:47:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9B86B04B1; Thu, 20 Jun 2024 07:47:42 -0400 (EDT) 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 7D2BD6B04AF for ; Thu, 20 Jun 2024 07:47:42 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 36169141A6B for ; Thu, 20 Jun 2024 11:47:42 +0000 (UTC) X-FDA: 82251092364.29.5ADAE5D Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf19.hostedemail.com (Postfix) with ESMTP id 58F551A000C for ; Thu, 20 Jun 2024 11:47:40 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sH+ExjKz; spf=pass (imf19.hostedemail.com: domain of glider@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718884051; 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=uDwdH5z/zkL6+tbqxf8Riv9fVhDg6OuGLlTLaC/xubk=; b=5vK4A5xjp6B4gPVt8pTIIPWS4R7vBLf7VdD3zdkvBU6xIeAao3nE98NiJ+6Oi/ShZEh9KX cFqZvGsSlEgbi0VrZoJZVnVO5Blsst8hLD0VkXC0vAwfhC/rYtD+IAbmwZqJfBcMZXEZKG IxGzEFHz5VwkRxr56VIQxOy37KLeJzs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718884051; a=rsa-sha256; cv=none; b=QsXEceXwkIepQVbehRI1KI5H1BtIV3MUmbcNvxppTQ+h85K9Ni/LBp2ers9a8Jg+8cuQXC jHPnUT3cwwmkFHmW/ekhmbDADIUhAA+11PoGFpqxeoqJWDqeVFo9LTjUP4RwelCxT+zexT wcHA3ucSmcZ6uoSqlAGLg3WCNw30ao8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sH+ExjKz; spf=pass (imf19.hostedemail.com: domain of glider@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6b5136965a7so2879686d6.1 for ; Thu, 20 Jun 2024 04:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718884059; x=1719488859; 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=uDwdH5z/zkL6+tbqxf8Riv9fVhDg6OuGLlTLaC/xubk=; b=sH+ExjKzhECb/p4KyRxYMeQu/kH/MdJP4K6CXQue7Y7yXJFJ4HRXrxn1+lPHkFXzrp i0Edrgwqvlg3KoWGGEkgzgdv4a0Xiq3Kp3EAjuHVn1hyYmQv/scc26vVNZcTwdpnoZL6 UlHULLbE6HB21Xxbll3VY2nLChfs1S/I6Pyq6cE9he/Yr77o7brfR8izRCvXa5cFKojz 9tPRye6SGQueEuB0vFNmZtNmMLmc9mBBZC+k9zuwMgGnqtXXxb+ytcUosj7MqNWa7AQj H3UfvmgULqQWCuSZT4DSeXFR5MCtycAkb6ocGD4d2byU+9mgzJ9KM5Ctkc5yCfFFjmYn X/SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718884059; x=1719488859; 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=uDwdH5z/zkL6+tbqxf8Riv9fVhDg6OuGLlTLaC/xubk=; b=NC5gSp4d9A3a604UYdD2q1URlFgm1ARHkKC0haVZqAiNO7ELX2OL5UiBMO02BktwSI FBPiRO1dVL+XH+iEQK5y5aRH1xf5+6Mp30BVD+VDm7xKXSGcARbhgoEDqaGwMQaDnTsV AIsvwC9F3JqtvS7L0zywv0XH2mdXReCmkeY6odJFxD0LKGQu++11goYF3+zVZz8gL4IP LsO4X0nuiBnnvzihtaIrrwMBjdBmzyTM+W5yu89bMUPJXzAtHiRMUiTvSC6HYf48WPbK raK0tPpiyLOZQdd5d1XkvQm1AXtDtAfvHfyLQoNKXnYNKaesAJo4OhkRThA1fIJIldOr T7rw== X-Forwarded-Encrypted: i=1; AJvYcCU81DBYSMmGCwjBSPzMKQO5F//cybJzIJ8Q6nZQ6+Kbdg96h0dFIY++KCKNSkjPP89qw3H7ta0yrWzTrcsK/yPy+lo= X-Gm-Message-State: AOJu0YwsHXS65DR5ojRwfIMNYEkyR+ceY71sOmNuGw1MhEdM2Zyonae+ FVVcZuEqNieYq7g38TA8vREuJpXsvyiLmJCPVuZwgdLyyT7Rxa4Opgk5vaT6f7/g2pMiOskRZvf PnHzwPcCgjQc2oMJEMqKdPWWaF3mopawJHvX1 X-Google-Smtp-Source: AGHT+IFTZb3hcmYsSPaMTpBvK5gmxppyrh4SewXIlDFuNry/LTMFMH5GyZM9u3XI0dP08A7JVHvNAIlAK7pDQ5tOFHQ= X-Received: by 2002:ad4:5a4e:0:b0:6b2:cb24:f395 with SMTP id 6a1803df08f44-6b50b2a314dmr32156226d6.39.1718884059087; Thu, 20 Jun 2024 04:47:39 -0700 (PDT) MIME-Version: 1.0 References: <20240619154530.163232-1-iii@linux.ibm.com> <20240619154530.163232-34-iii@linux.ibm.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 20 Jun 2024 13:46:57 +0200 Message-ID: Subject: Re: [PATCH v5 33/37] s390/uaccess: Add KMSAN support to put_user() and get_user() To: Ilya Leoshkevich Cc: Alexander Gordeev , Andrew Morton , Christoph Lameter , David Rientjes , Heiko Carstens , Joonsoo Kim , Marco Elver , Masami Hiramatsu , Pekka Enberg , Steven Rostedt , Vasily Gorbik , Vlastimil Babka , Christian Borntraeger , Dmitry Vyukov , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Mark Rutland , Roman Gushchin , Sven Schnelle Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: hbe9r6jim97f95m3b7owjhcz1w95g851 X-Rspamd-Queue-Id: 58F551A000C X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718884060-847617 X-HE-Meta: U2FsdGVkX18V75FzolOGuMoBnGijGMcu1ByJI57HuYUmbWTV0kBoFpzmWwvh+lJTDKQmsqbgaS57/KR3g8DO0ZGKsufZP8GGm9YyDGYJ8gVnaZYQfi6uuUjNWEqbY7nn+tMXrZbTh7vv1q/5MlLR9MrDqpqnutep8LYcyro/WYOGhjf3KkPyqESKIMGbnzs+PUj8lmOgsmE77/A/4zg0P66/6IZLrvKQ83ChT9MhVIQ4Pd8nY0XlzSXgdybnJagLvNdyggBEpfWQZR4i8xZ/uuIu8isuxed1rb/KwYxFjoXdtaukm98BMIVnBicGfo5VL0bG/B12RwIjoNPIJl1MgVxWHIa1gwOVxJlHVDo0pPGYbePNjtyGZ18UxazGCbs74SpQlae0A5dvzxzsrJ7ICDGTluqyjQs7yO/+366n4cwWGpuj73Eq6wpMF3FO7fi1g9WODUUfCzUzS0Jc8JiAaLhZeE1UF1l3J5z2o67pn5odPFKxNvdH+EwLSERPxp09ocgmKFaXpf4jbf6rN+CyAIdld1HoGDD1v78Mwf8fQzRkFF6XUwITNaRP616cArwVyKttRTDGmZV8+tqoJ7TVcfDglRJ5H/4CoxWsSTI4evhctbH92+ncA+QBV4AFiW8trgeSougQeQ5cwmw+NIRJI3ECheEZG8jqdRAJ1dKNDd8hQo8IwLTRrIeYvPkYfECDFes8yaPG1x9sGNCrcePQjfLZr31tfLaKIyF2PETHXD7qaMqlLVpy85TKvruUX4SuMXO57fGaqkpyUX9KsJJcsjyH1pA40L+J8oRSs+XFAghooONfW6dJYl0IVB6nt8hW6Irx5+ruOSxtYBpGlsBNNN7lpBwNYQCItYXaVMWUaXTaypjG/H6e0yM3Xelzp0/XTIQKzzEC8Ow5AN5lyqzDZF/VQWbYlaxH57gdFLF3x4rH1x1VLWOigFQ0BeQYeHPcSuFVPkPqSoKoVFSZH1E IxOk8cG0 R6y+e1PuRTEqhgu7daumOcj20UmoXGQB2eRomD9MQjrz7IAKT7FQUwVXWqn4pohvHmpGmCalcIda3489lYAwNV7F5HKBWFYZwN1stX1m9bFxQzEIxleGquU7a3D36Y5lKJDAeGEoNNNjXPcscLum4i1K1wSsfKBToYIM6Q1XNQFfj7sV2JTBFd9G/hmtZqb0fX9C77JL3vo4v00OcKLU9zlfHWiN3f5E+xmbCjBFUdftwppV5WYgVhv+jdVTqyA8QcDu2nAxzyCABwtMBho9fDLDbO8beoAYXtMm1jEzFWHed1u5LBXVZlcMbGsm6elupQN7knhFgn4X4w0BK5yyITVuuNQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.090018, 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, Jun 20, 2024 at 1:19=E2=80=AFPM Ilya Leoshkevich wrote: > > On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote: > > On Wed, Jun 19, 2024 at 5:45=E2=80=AFPM Ilya Leoshkevich > > wrote: > > > > > > put_user() uses inline assembly with precise constraints, so Clang > > > is > > > in principle capable of instrumenting it automatically. > > > Unfortunately, > > > one of the constraints contains a dereferenced user pointer, and > > > Clang > > > does not currently distinguish user and kernel pointers. Therefore > > > KMSAN attempts to access shadow for user pointers, which is not a > > > right > > > thing to do. > > > > By the way, how does this problem manifest? > > I was expecting KMSAN to generate dummy shadow accesses in this case, > > and reading/writing 1-8 bytes from dummy shadow shouldn't be a > > problem. > > > > (On the other hand, not inlining the get_user/put_user functions is > > probably still faster than retrieving the dummy shadow, so I'm fine > > either way) > > We have two problems here: not only clang can't distinguish user and > kernel pointers, the KMSAN runtime - which is supposed to clean that > up - can't do that either due to overlapping kernel and user address > spaces on s390. So the instrumentation ultimately tries to access the > real shadow. > > I forgot what the consequences of that were exactly, so I reverted the > patch and now I get: > > Unable to handle kernel pointer dereference in virtual kernel address > space > Failing address: 000003fed25fa000 TEID: 000003fed25fa403 > Fault in home space mode while using kernel ASCE. > AS:0000000005a70007 R3:00000000824d8007 S:0000000000000020 > Oops: 0010 ilc:2 [#1] SMP > Modules linked in: > CPU: 3 PID: 1 Comm: init Tainted: G B N 6.10.0-rc4- > g8aadb00f495e #11 > Hardware name: IBM 3931 A01 704 (KVM/Linux) > Krnl PSW : 0704c00180000000 000003ffe288975a (memset+0x3a/0xa0) > R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 > Krnl GPRS: 0000000000000000 000003fed25fa180 000003fed25fa180 > 000003ffe28897a6 > 0000000000000007 000003ffe0000000 0000000000000000 > 000002ee06e68190 > 000002ee06f19000 000003fed25fa180 000003ffd25fa180 > 000003ffd25fa180 > 0000000000000008 0000000000000000 000003ffe17262e0 > 0000037ee000f730 > Krnl Code: 000003ffe288974c: 41101100 la %r1,256(%r1) > 000003ffe2889750: a737fffb brctg > %r3,000003ffe2889746 > #000003ffe2889754: c03000000029 larl > %r3,000003ffe28897a6 > >000003ffe288975a: 44403000 ex %r4,0(%r3) > 000003ffe288975e: 07fe bcr 15,%r14 > 000003ffe2889760: a74f0001 cghi %r4,1 > 000003ffe2889764: b9040012 lgr %r1,%r2 > 000003ffe2889768: a784001c brc > 8,000003ffe28897a0 > Call Trace: > [<000003ffe288975a>] memset+0x3a/0xa0 > ([<000003ffe17262bc>] kmsan_internal_set_shadow_origin+0x21c/0x3a0) > [<000003ffe1725fb6>] kmsan_internal_unpoison_memory+0x26/0x30 > [<000003ffe1c1c646>] create_elf_tables+0x13c6/0x2620 > [<000003ffe1c0ebaa>] load_elf_binary+0x50da/0x68f0 > [<000003ffe18c41fc>] bprm_execve+0x201c/0x2f40 > [<000003ffe18bff9a>] kernel_execve+0x2cda/0x2d00 > [<000003ffe49b745a>] kernel_init+0x9ba/0x1630 > [<000003ffe000cd5c>] __ret_from_fork+0xbc/0x180 > [<000003ffe4a1907a>] ret_from_fork+0xa/0x30 > Last Breaking-Event-Address: > [<000003ffe2889742>] memset+0x22/0xa0 > Kernel panic - not syncing: Fatal exception: panic_on_oops > > So is_bad_asm_addr() returned false for a userspace address. > Why? Because it happened to collide with the kernel modules area: > precisely the effect of overlapping. > > VMALLOC_START: 0x37ee0000000 > VMALLOC_END: 0x3a960000000 > MODULES_VADDR: 0x3ff60000000 > Address: 0x3ffd157a580 > MODULES_END: 0x3ffe0000000 I see, thanks for the clarification! > Now the question is, why do we crash when accessing shadow for modules? > I'll need to investigate, this does not look normal. But even if that > worked, we clearly wouldn't want userspace accesses to pollute module > shadow, so I think we need this patch in its current form. Ok, it indeed makes sense. Reviewed-by: Alexander Potapenko